Subject: Re: Review of draft-ietf-ipv6-2461bis-09.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 01 Dec 2006 20:16:55 +0900

>>>>> On Wed, 29 Nov 2006 14:48:40 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

>>> How, exactly, is this padding encoded?  And, why bother?
>> 
>> See the length field:
>> 
>> Length         8-bit unsigned integer.  The length of the option
>> (including the type and length fields) in units of
>> 8 octets.  The value 0 is invalid.  Nodes MUST
>> silently discard an ND packet that contains an
>> option with length zero.
>> 
>> You have to pad options to fill them out to 8 octets.  

> Oh, of course...

> OK, so "natural 64-bit boundaries" is a little unclear.  And, shouldn't it
> be a MUST?  Does each option describe how to pad; i.e., suppose an option
> carries a single variable length value?  Is it the responsibility of the
> text defining the option to describe the format of the option so the option
> is always a multiple of 8 octets?

I don't know the original intent, but RFC2497 defines an ND option
with a 5-byte option field.  This may indicate it was expected that
documents that specify options were responsible for specifying
necessary padding as well.

> Backtracking...I reviewed the options defined in this spec, and all except
> the Redirected-header option are defined to be an integer multiple of 8
> octets in length.  So, is the "padded when necessary" advice for the
> definition of future options?

Good point...I recently found the following comment lines in the
KAME/BSD implementation of sending a Redirect message:

		/*
		 * Redirected header option spec (RFC2461 4.6.3) talks nothing
		 * about padding/truncate rule for the original IP packet.
		 * From the discussion on IPv6imp in Feb 1999,
		 * the consensus was:
		 * - "attach as much as possible" is the goal
		 * - pad if not aligned (original size can be guessed by
		 *   original ip6 header)
		[...]

I don't remember "the discussion on IPv6imp", but this comment shows
the implementor community found the spec unclear on this and reached a
"consensus" that there should be a padding if the length of the
enclosed packet is not a multiple of 8 octets.

I'm not sure if we want to clarify this point in 2461bis, though.  I
personally think the clarification (whatever it is) is basically
compatible with existing implementations, but it may affect some
existing implementations, and it may look an "incompatible change" for
some implementors...

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 23 Dec 2006 01:14:43 +1100

Hi Ralph and Thomas, 

Just updating the doc for final (hopefully!) submission. 
A couple of conclusions from the discussion below are unlear to me. So your
responses will help me clarify the new document. 

 > >> Substantive/editorial: I'm confused by the statements in 
 > section 3.2,
 > >>            Supported Link Types: "Neighbor Discovery 
 > should be implemented
 > >>            as described in this document."  What is the 
 > intent of the
 > >>            statement - advice about whether to implement or how to
 > >>            implement?  Under what circumstances would a 
 > node not implement
 > >>            Neighbor Discovery as described in the document.
 > > 
 > > I think this is general advice to people thinking about 
 > how ND applies
 > > to link layers other than, say, ethernet. Clearly, ND 
 > applies to all
 > > specs, unless superceded by another spec for a particular link
 > > layer. That is all that this section is (IMO) trying to 
 > say. I.e., to
 > > suggest when another spec might be needed and where not.
 > 
 > I think I understand the meaning the text is supposed to 
 > convey.  But the
 > text doesn't seem (to me, anyway) to convey that meaning 
 > very well; I note
 > your interpretation is qualified with "IMO" and perhaps 
 > another reader might
 > have a different opinion?
 > 
 > To be more concrete, it appears that the section is 
 > describing how or which
 > parts of ND should be implemented on links with certain 
 > attributes.  But the
 > last several entries don't seem to be very clear or precise. 

=> Ok, does anyone object to removing that statement from the spec?
The statemement I'm referring to is the one Ralph refers to above:
"Neighbor Discovery should be implemented as described in this document."
It seems superfluous anyway. 

 > >> Substantive: From section 4.6, Option Formats:
 > > 
 > >>    Options should
 > >>    be padded when necessary to ensure that they end on 
 > their natural 64-
 > >>    bit boundaries.
 > > 
 > OK, so "natural 64-bit boundaries" is a little unclear.  

=> I believe RFC 2460 uses the same language.

 > And, shouldn't it

=> Yes, that's my understanding. 

  Hm, if that's the case, 
 > then perhaps the
 > text I quoted is superfluous?

=> Maybe a healthy redundancy :)

 > definition of future options?

=> Sure.

 > >>            option, includes:
 > > 
 > >>                      When
 > >>                      not set the advertisement makes no 
 > statement about
 > >>                      on-link or off-link properties of the prefix.
 > > 
 > >>            This point about "no statement about on-link or
 > >>            off-link..." is made other places, as well.  I 
 > don't think
 > >>            I see any indication of the consequences of this
 > >>            definition; that is, what should the 
 > implementor be aware
 > >>            of as a consequence of the lack of knowledge 
 > about whether
 > >>            a prefix is on-link or off-link?  If those 
 > consequences are
 > >>            subtle, perhaps they should be explained?
 > > 
 > > Well, I seem to recall that exact wording was the result 
 > of a lot of
 > > discussion at the time. :-)
 > > 
 > > What this is really trying to say is that if you receive 
 > an RA with a
 > > prefix information option in which the on-link bit is not set, you
 > > cannot conclude from that that the prefix is not on link. 
 > From section
 > > 6.3.4:
 > > 
 > >    Prefix Information options that have the "on-link" (L) flag set
 > >    indicate a prefix identifying a range of addresses that 
 > should be
 > >    considered on-link.  Note, however, that a Prefix 
 > Information option
 > >    with the on-link flag set to zero conveys no 
 > information concerning
 > >    on-link determination and MUST NOT be interpreted to mean that
 > >    addresses covered by the prefix are off-link.  The only 
 > way to cancel
 > >    a previous on-link indication is to advertise that 
 > prefix with the
 > >    L-bit set and the Lifetime set to zero.
 > > 
 > > The last sentence explains why "when not set the 
 > advertisment makes no
 > > statement about on-link or off-link properties of the prefix".
 > 
 > Yeah, I agree the text means "don't draw any conclusions about on- or
 > off-link is L bit is not set".  What are the ramifications 
 > of the L bit not
 > being set; what other parts of this or other protocols are affected?

=> If the L bit is not set a host cannot assume that an address is on-link,
therefore it will send all packets to its Default router, unless a redirect
is received for a particular address. 

 > 
 > >> Editorial/substantive: From section 5.1, Conceptual Data 
 > Structures:
 > > 
 > >>       Default Router List
 > >>                    - A list of routers to which packets 
 > may be sent.
 > > 
 > >>            Is it possible for a host to send packets to 
 > routers that
 > >>            are not on the Default Router list?
 > > 
 > > sure, but that  is outside the scope of this spec. The only routers
 > > covered by the ND spec are those learned via ND.
 > 
 > So a host only learns about default routers through ND?

=> I don't think your sentence above is related to being able to send
packets to other routers. Learning about default routers is specified in
this doc, but your original question was whether a host can send packets to
other routers (not the default) and I agree with Thomas' answer. But I don't
see how that means that a host can only learn about a DR from ND? Seems like
a completely separate point.

 > > Agreed. I suggest dropping autonomous, since that term is less well
 > > known.
 > 
 > Except for its use in supplying the initial for the 'A' bit in prefix
 > options...

=> I agree. So how about we state in the document that the terms "stateless
autoconfiguration" and "autonomous autoconfiguration" are used
interchangeably? People are familiar with the meaning of the A flag and with
the term "stateless autoconfig", removing either one is probably going to
add more confusion than clarity. It might have to be one of those
imperfections of a doc that developed over a long time. Is this ok?

 > > Not necessarily. See RFC RFC3775.
 > 
 > Ah, right, thanks for the pointer.  Just for my own 
 > enlightenment, is there
 > a reason to advertise a prefix that has all three of L, A 
 > and R not set;
 > i.e., a prefix not used for IPv6 mobility, not used for SLAAC and not
 > on-link?

=> I can't think of a useful application that would benefit from this. 

Hesham

  And, I guess this follows up on my earlier 
 > question - if the L bit
 > is not set, I suppose it means the prefix is not added to the list of
 > on-link prefixes as a result of receiving the prefix option in an RA.
 > 
 > > Thomas
 > 
 > - Ralph
 >

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Dec 2006 16:02:16 +0100

Hesham Soliman wrote:
> Hi Ralph and Thomas,
> 
> Just updating the doc for final (hopefully!) submission. A couple of 
> conclusions from the discussion below are unlear to me. So your 

Hi Hesham, please allow me to interfere, splitting the thread to a
different topic.  I do not give an oppinion in this message about the
original message's comments.

Do you or co-authors think it may be useful to add several
clarifications in the 2461bis with respect to how ND would run on
point-to-point links?

For example, the draft says multicast 'can' be trivially provided on
point to point links, and interfaces 'can' be assigned link-local
addresses.  But does this mean that a host should do a MLD JOIN on a
point to point link.  Does this mean that a packet sent to a link-local
multicast address sent by one end should be received by the other w/ or
w/o doing MLD  JOIN.  Does this mean the node should join the
solicited-node multicast address (derived from its IID) when over a
point-to-point link?

Another aspect is the use of S/TLLAOs on links with no link-layer
headers, typically point to point.  For example, is it mandatory to
_not_ use S/TLLAOs if there's no link-layer header, or should they be
used instead.

For example this text:
> Target link-layer address The link-layer address for the target, 
> i.e., the sender of the advertisement.  This option MUST be included 
> on link layers that have addresses when responding to multicast 
> solicitations.  When responding to a unicast Neighbor Solicitation 
> this option SHOULD be included.

First, should a NS over point to point link be unicasted or multicasted,
in terms of its dst address.  Second, it says this option MUST be
included when link-layer has addresses.  It doesn't say it shouldn't be
included if the link-layer doesn't have addresses.  I think it should
either say that or its contrary, but not be silent on this.

Finally, link-layer addresses have a tight relationship with what goes
in the last 64bits of an address.  On ppp (and maybe others?) links
there's no link-layer address but there's means to have something go
into the last 64bits.  So could we consider that IID to be a link-layer
address.

Maybe no: because the Ethernet link-layer protocol never uses an IID for
its inner addressing.

Maybe yes: because on ppp it's the link-layer (or 2.5 layer IPv6CP)
negotiates this IID.  Besides, putting an IID in an SLLAO can help make
NS/NA work over multicast point-to-point links when no link-layer header.

What do you, co-authors and WG members think, am I completely off-mark. 
Thanks,

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 22 Dec 2006 09:49:14 -0800

> => I can't think of a useful application that would benefit 

I gave one useful application (landmark prefix for a link).

Fred
[email-masked]

---

From: Lican Huang <[email-masked]>
Date: Sat, 23 Dec 2006 12:54:44 +0000 (GMT)

Could someone kindly give the tool for writing  the draft?
   
  Thanks a lot.
   
  Best regards,
   
  Lican 

Fred

Dr. Lican Huang, Director 

Institute of Network&Distributed Computing 

Zhejiang Sci-Tech University 

http://virgo.sourceforge.net/ 

 Send instant messages to your online friends http://uk.messenger.yahoo.com