Subject: RE: W.G. Last Call on "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification"

From: "Peter Tam" <[email-masked]>
Date: Fri, 30 Jun 2000 13:05:27 -0500

Alex: Please see inserts.... Peter

	-----Original Message-----
	From:	Alex Conta [SMTP:[email-masked]]
	Sent:	Thursday, June 29, 2000 11:13 AM
	To:	Tam, Peter [NORSE:6L73:EXCH]
	Cc:	Bob Hinden; [email-masked]
	Subject:	Re: W.G. Last Call on "Extensions to IPv6 Neighbor
Discovery for  Inverse Discovery Specification"

	Peter,

	Thank you for your comments, which are important for the improving
of
	this specification.
	For the first comment, I need more clarification, but it is probably
	better if I take the comments and answer them one by one, so please
see
	bellow:

	Peter Tam wrote:

	>
	>
	> Bob:
	>
	> This is the 1st time I read this draft. Apology if the following
have
	> been discussed before:
	>
	>   1. 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.
	>

	Would you please elaborate?
	>> Currently, the draft does not restrict the types of addresses
within the Source/Target Address Lists in the IND Solicitation/Advertisement
messages. Thus, it implies that both unicast and multicast addresses are
legitimate. This address information is used to build the Neighbor cache,
which I believe can contain only unicast addresses. If unicast-only
addresses are imposed (as I suggested), then Sections 4.3.1 and 4.3.2 should
discard IND messages containing multicast addresses, so that they will not
be entered into the cache. After all, resolution should be between link
layer addresses and unicast network addresses.

	>   1. 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.
	>
	The motivations to the present text in the specification were the
	following:

	1. Minimizing and possibly eliminating unsolicited messages is a
good
	thing.

	2. The scenario in which one or more new IPv6 address are added to
an
	existent VC can be solved by having the node adding such addresses
send
	IND Solicitation(s).

	3. The scenario in which one ore more IPv6 addresses associated with
a
	VC are deleted while the VC and DLCI remain was envisaged to happen
	seldom - more often, the VC and DLCI would be torn down as well   -
and
	be resolved through the IPv6 address deprecation.

	>> There are 2 possible ways of providing changed IP address (added
or deleted) information using IND. First way is for the node that changes
its IP address(es) to use an unsolicited IND Advertisement message to
identify all the source IP addresses on that interface. The 2nd is for that
node to use an IND Solicitation message to identify all the source IP
addresses. The IND advertisement approach would have to add an S-bit to the
advertisement message, changing message format in the current draft. But it
involves 1 message type, the Advertisement. Secondly, the IND solicitation
approach does not change the current message formats, but will double the
amount of IND traffic with an advertisement response. Need only 1 approach.

	>   1. 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.
	>

	The appendix was intended to contain one simple example to
illustrate
	the use of the protocol. Some particular details of the link in the
	example were considered out of scope.
	>> Out-of/in scope is an artificial line. In this case, all it takes
is only 1 line of clarification.

	>   1. Why is there a preference of FR to ATM in Appendix A? Should
also
	>      include the case for ATM as a link-layer technology.
	>
	>

	As said previously, the appendix contains just one example, to
	illustrate simply and briefly the use of the protocol. Although it
is
	mentioned that it may apply to other link technologies, it was not
	intended to cover more or all possible link technologies.
	>> Yes, I agree. 1 scenario is as good as 2 or 3 if they are
similar. Moreover, you did indeed state the intent in the Abstract. Also, I
am a FR supporter.

	> Regards... Peter Tam,
	> Nortel Networks, Ottawa

	Thank you,
	Alex Conta
	Transwitch Corporation, Shelton, CT

	>
	>
	>      -----Original Message-----
	>      From:   Bob Hinden [SMTP:[email-masked]]
	>      Sent:   Thursday, June 22, 2000 4:27 PM
	>      To:     [email-masked]
	>      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-masked]
	>
	>
-------------------------------------------------------------------