Alex: Please see inserts.... Peter
-----Original Message-----
From: Alex Conta [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, June 29, 2000 11:13 AM
To: Tam, Peter [NORSE:6L73:EXCH]
Cc: Bob Hinden; [EMAIL PROTECTED]
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 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]
>
> -------------------------------------------------------------------
>
