Dear 6MANers As we know, the current usage of IPv6 ND is based on the reactive method where a node is queried on-demand, upon a packet for a neighbor for which the link layer address is not resolved yet.
It appears that a proactive (stateful) ND method could be useful in a number of cases: - P2MP/NBMA where Inverse ND (RFC3122) is classically defined as a plain IPv6 adaptation of I-ARP - PPP because IPv6 CP does not negotiate addresses but IIDs - Any interface for Source Address Validation with SeND Inverse ND is the only such method currently available though 6LoWPAN is designing an ND registration mechanism that has different properties. 3122 could be improved in a number of fashions: - the mechanism does not enable to manage the list of addresses as they are added/removed properly - there are typos such as a 7bit length field in the address list option - RFC 3122 is explicitely defined for Frame Relay (and similar) thus the limited interest from the community. Support for all types of links should be defined to enable stateful ND. - it makes sense to add the support of SeND for P2MP and transit networks. draft-thubert-3122bis proposes a rework of RFC 3122. The proposed changes for the support of SeND does not add anything complex crypto-wise so we expect that 6MAN is the best place for this whole work to take place. What do you think? Pascal >-----Original Message----- >From: IETF I-D Submission Tool [mailto:[EMAIL PROTECTED] >Sent: jeudi 23 octobre 2008 15:50 >To: Pascal Thubert (pthubert) >Cc: Eric Levy- Abegnoli (elevyabe) >Subject: New Version Notification for draft-thubert-3122bis-00 > > >A new version of I-D, draft-thubert-3122bis-00.txt has been successfuly submitted by Pascal Thubert >and posted to the IETF repository. > >Filename: draft-thubert-3122bis >Revision: 00 >Title: IPv6 Inverse Neighbor Discovery Update >Creation_date: 2008-10-23 >WG ID: Independent Submission >Number_of_pages: 14 > >Abstract: >This draft updates the Inverse Discovery Specification [RFC3122] to >provide Secure Neighbor Discovery. The behaviour of the protocol is >slightly amended to enable an easier management of the addresses on a >link and enable Secure ND. > > > >The IETF Secretariat. > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
