1 / 8

NDProxy Update draft-thaler-ipv6-ndproxy-02.txt

NDProxy Update draft-thaler-ipv6-ndproxy-02.txt. Dave Thaler Mohit Talwar Chirayu Patel. Status. http://www.icir.org/dthaler/NDProxyIssues.htm All issues from before last IETF closed New editorial issues submitted Say when bridging is sufficient (Pekka Savola)

tiger-cunningham
Download Presentation

NDProxy Update draft-thaler-ipv6-ndproxy-02.txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NDProxy Updatedraft-thaler-ipv6-ndproxy-02.txt Dave ThalerMohit TalwarChirayu Patel IETF 59 - Seoul

  2. Status • http://www.icir.org/dthaler/NDProxyIssues.htm • All issues from before last IETF closed • New editorial issues submitted • Say when bridging is sufficient (Pekka Savola) • Add examples to protocol guidelines (Pekka Savola) • New technical issues submitted • AH removal (Pekka Savola) • Segments with differing MTUs (Chirayu Patel) • IPv4 support (Chirayu Patel) IETF 59 - Seoul

  3. Issue 12: AH removal • Removing AH from a proxied packet may cause a packet to be dropped due to security policy • SEND doesn’t use AH, so proxied packets won’t have AH anyway • Change in -02: remove all mention of AH removal IETF 59 - Seoul

  4. Issue 13: Segments with differing MTUs • Previously had non-goal to support segments with different MTU • But 1 of the 2 scenarios (PPP upstream) has different MTUs • Previously said NDproxy added/updated MTU option when proxying RA in scenario 2 • but this can cause failure if adding doesn’t fit IETF 59 - Seoul

  5. Issue 13 (cont) • RFC 2461 section 4.6.4 says about this case: • If the bridges do not generate ICMP Packet Too Big messages, communicating nodes will be unable to use Path MTU to dynamically determine the appropriate MTU on a per-neighbor basis. In such cases, routers use the MTU option … • Change in -02: • NDproxy generates Packet Too Big Message • Remove all mention of modifying RAs IETF 59 - Seoul

  6. Issue 10: IPv4 support • Should IPv4 support be left in or removed? • Draft discusses NDproxy in terms of IPv6 neighbor cache states • Draft -02 just adds “For readability, we will describe the neighbor cache as if both IPv4 and IPv6 neighbors use the same state machine described in [ND].” • IPv4 support comes mostly for free with the above caveat • Options: • Leave it with the above caveat • Remove all mention of IPv4 support • Put IPv4 support in an appendix IETF 59 - Seoul

  7. Other comments? IETF 59 - Seoul

  8. Issue 11: Say when bridging is sufficient • Response: • Already says bridging should be used except where it can't work, and enumerates the two cases where it doesn't.  • Hence, every scenario which has neither limitation is a bridging scenario. • Proposed resolution: reject as out of scope IETF 59 - Seoul

More Related