multiple care of address registration
play

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,


  1. Multiple Care-of Address Registration draft-ietf-monami6-multiplecoa-04.txt Ryuji Wakikawa IETF 70th MEXT WG

  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

  3. Alternate CoA option  For binding update protected by ESP, Alternate CoA option MUST be presented [RFC3776]  BID option is used as a substitute of Alternate CoA option  BID option carries the Care-of Address when C flag is set

  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

  5. DSMIPv6 Support  No support for IPv4 CoA  BID option can be extended to carry IPv4 CoA instead of IPv4 CoA option

  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

  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 option

  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

  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  Internet mobile node is attached to the home link. This flag is valid for Home Registration, Deregistration and bulk registration. Binding Assumption  2001::2 - 2001::2 BID-1(H) when H flag is used, HA MUST NOT use HA  3ffe::1 BID-2 Proxy ND to intercept packets for MN on the home link. 2001::1 (HA) draft-wakikawa-mip6-no-ndp-01.txt  2001::2 (HoA) MN 3ffe::1 (CoA)

  10. Comments from Keigo (Slide used in IETF67) Binding  When MN returns home, it 2001::2 - 2001::3 HA creates CoA from its home prefix (Home-CoA) and registers 2001::1 (HA) it to HA IP-in-IP tunnel 2001::3 (home-CoA) Advantage  MN MN can utilize an interface  2001::2 (HoA) attached to the home link and other interfaces attached to foreign links Issues  The definition of HoA and CoA  Binding (RFC3775) is modified. 2001::2 - 2001::3 - MNP HA MN starts NS for the destination  located on the home link (bypass 2001::1 (HA) tunnel?) Priority of NDP/Routing Table/Binding IP-in-IP tunnel 2001::3 (home-CoA)  Cache?? MR I’m afraid of side-effect of this 2001::2 (HoA)  changes. (ex. IKE?, MR routing update, etc) MNP

  11. Operational Solution for returning home (Slide used in IETF67) Binding If a home link is multihomed (i.e. 2001::2 - 2002::3  HA advertising one home prefix and another foreign prefix), similar 2001::1 (HA) configuration can be achieved IP-in-IP tunnel 2002::3 (CoA) MN 2001::2 (HoA) HA No returning home 2001::1 (HA) HA RA (2001::/64 and 2002::/64) 2001::1 (HA) 2001::2 (HoA) MN 2001::2 (HoA) MN Returning Home

  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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend