Multiple Care-of Address Registration - - PowerPoint PPT Presentation

multiple care of address registration
SMART_READER_LITE
LIVE PREVIEW

Multiple Care-of Address Registration - - PowerPoint PPT Presentation

Multiple Care-of Address Registration draft-ietf-monami6-multiplecoa-04.txt Ryuji Wakikawa IETF 70th MEXT WG Updates from -03 Change the handling of Status field. All the status value is defined for BA Alternate CoA option is omitted,


slide-1
SLIDE 1

Multiple Care-of Address Registration

draft-ietf-monami6-multiplecoa-04.txt

Ryuji Wakikawa IETF 70th MEXT WG

slide-2
SLIDE 2

Updates from -03

 Change the handling of Status field. All the status

value is defined for BA

 Alternate CoA option is omitted, but using C flag is

recommended.

 Many editorial updates

slide-3
SLIDE 3

Alternate CoA option

 For binding update protected by ESP, Alternate CoA

  • ption MUST be presented [RFC3776]

 BID option is used as a substitute of Alternate CoA

  • ption

 BID option carries the Care-of Address when C flag is set

slide-4
SLIDE 4

Status Code

 Two status cods in binding acknowledgement

 status field in binding acknowledgement  status field in BID option

 If the status value in BID set to zero, the receiver

uses the status value in BA for all the bindings specified in BA. Otherwise, it uses the status value in BID

 examples

 [BA, status=0][BID, status=0] -> Accepted  [BA, status=0][BID, status=128] -> Reason Unspecified

slide-5
SLIDE 5

DSMIPv6 Support

 No support for IPv4 CoA  BID option can be extended to carry IPv4 CoA

instead of IPv4 CoA option

slide-6
SLIDE 6

Bulk Registration for CN

 Bulk registration is only valid for home registration  In order to support RO, we need certain extension to

RR in order to carry multiple CoAs at once

 We had consensus not to support RO in the monami6 WG

because of protocol simplicity

slide-7
SLIDE 7

RR with Bulk Registration

(slide used in IETF65)

 When multiple CoAs are in a Binding Update

 Authenticator cannot be calculated for all CoAs

No authentication for all CoAs

 Two options

forget bulk registration for CNs. Using separate binding update for CNs

Extending BID option to carry authenticator. Keep the home/careof nonce index and authenticator in the BID

  • ption
slide-8
SLIDE 8

Simultaneously Home and Foreign attachments (The slide used in IETF65)

 Three options when MN returns home

 keep IF attached to the home link  deregistering binding (HA stop proxy ND)  keep IF attached to the foreign link  disable the interface attached to home (HA keep proxy ND)  keep both IFs  how??

 The problem when MN uses both IF@home/foreign

 HA cannot intercept packets when MN returns home

because it stop proxy ND

 If HA keep proxy ND, DAD will be occurred

slide-9
SLIDE 9

H flag for BID sub-option (Slide used in IETF69)

MN utilize interfaces attached to home and foreign links simultaneously with H flag set in BID sub-option

Home Binding (H) flag indicates that the mobile node is attached to the home link. This flag is valid for Home Registration, Deregistration and bulk registration.

Assumption

when H flag is used, HA MUST NOT use Proxy ND to intercept packets for MN on the home link.

draft-wakikawa-mip6-no-ndp-01.txt

HA MN

2001::1 (HA) 2001::2 (HoA) Binding 2001::2 - 2001::2 BID-1(H) 3ffe::1 BID-2

Internet

3ffe::1 (CoA)

slide-10
SLIDE 10

Comments from Keigo

(Slide used in IETF67)

 When MN returns home, it

creates CoA from its home prefix (Home-CoA) and registers it to HA

Advantage

MN can utilize an interface attached to the home link and other interfaces attached to foreign links

Issues

The definition of HoA and CoA (RFC3775) is modified.

MN starts NS for the destination located on the home link (bypass tunnel?)

  • Priority of NDP/Routing Table/Binding

Cache??

I’m afraid of side-effect of this

  • changes. (ex. IKE?, MR routing

update, etc)

HA MN

2001::1 (HA) 2001::2 (HoA) 2001::3 (home-CoA) IP-in-IP tunnel Binding 2001::2 - 2001::3

HA MR

2001::1 (HA) 2001::2 (HoA) 2001::3 (home-CoA) IP-in-IP tunnel Binding 2001::2 - 2001::3 - MNP MNP

slide-11
SLIDE 11

Operational Solution for returning home (Slide used in IETF67)

If a home link is multihomed (i.e. advertising one home prefix and another foreign prefix), similar configuration can be achieved

HA MN

2001::1 (HA) 2001::2 (HoA)

HA MN

2001::1 (HA) 2001::2 (HoA) 2002::3 (CoA) IP-in-IP tunnel

HA MN

2001::1 (HA) 2001::2 (HoA) Binding 2001::2 - 2002::3 RA (2001::/64 and 2002::/64)

Returning Home No returning home

slide-12
SLIDE 12

Comments from Vijay

 MN does not defend its HoA at the home link if HA

still keeps bindings

 Let HA intercept all the packet first and tunnel/forward to

MN by one of registered bindings

 For sending and receiving packets at the interface

attached to home link

 HA learns the L2 address of the interface  MN learns the L2 address of the HA  Using learned L2 address to construct packets