Bob:
This is the 1st time I read this draft. Apology if the following have been discussed before:
- Must the Target Address List option in the Inverse Neighbor Discovery Advertisement (InvNDA) message not contain unicast IPv6 addresses only? I think it must. Then it will affect section 4.3.2 on the validation procedures.
- Should it not also support unsolicited InvNDA, when 1 or more of an inteface's IP addresses have been changed? It should, and should also enforce to re-advertise all the addresses on that interface. Otherwise, it is not possible to cover the scenario where an IP address on the interface was deleted.
- Appendix A: Frame Relay (FR) as a link-layer address. But it should have a note up front that the DLCI applies to the member DLCI in the case of a Multi-link Frame Relay.
- Why is there a preference of FR to ATM in Appendix A? Should also include the case for ATM as a link-layer technology.
Regards... Peter Tam,
Nortel Networks, Ottawa
-----Original Message-----
From: Bob Hinden [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, June 22, 2000 4:27 PM
To: [EMAIL PROTECTED]
Subject: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"
This is a IPng working group last call for comments on advancing the
following document as a Proposed Standard:
Title : Extensions to IPv6 Neighbor Discovery for Inverse
Discovery Specification
Author(s) : A. Conta
Filename : draft-ietf-ion-ipv6-ind-03.txt
Pages : 22
Date : 27-Oct-99
Please send substantive comments to the ipng mailing list, and minor
editorial comments to the author. This last call period will end two
week from today on July 6, 2000.
Bob Hinden / Steve Deering
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
