Re: [rrg] Last call for revised ILNP documents [Corrected]

["George, Wes" <[e-mail]>]

I know I'm also late, but I do have a few comments on the assembled documents.

I support publication as well.

Ilnp-arch:

3.3 - Regarding the naming, I think that Identifier-Locator Vector seems fine, but I think you should drop the hyphen from the acronym. Based on the way that you're writing the term, the acronym should be either I-LV or ILV.
Also, your choice of notation <I,L> somewhat conflicts with the notation being used in 3.4 eg <TCP: I_L, I_R, P_L, P_R><ILNP: L_L, L_R>
It would be helpful if these were consistent, perhaps by adding the use of [] or {} as separators as appropriate instead of overloading the <> symbols. However, I do not recommend use of parentheses due to potential for confusion with the Multicast (s,g) notation.


6.1 - The advent of mobile phones with tethering capabilities sort of blur the distinction that you make here. A mobile node can also be its own network with subtended devices, meaning that in a way it is both host mobility and Network/site mobility. I don't think that this fundamentally alters anything about the implementation so much as it's worth noting for completeness. It seems that this is mostly discussed in 6.2, so it may be possible to simply cite this as an additional example.

Nits
- need to replace section x.y with correct reference:
3.2
 "Section X.Y below describes in more
   detail how Locators are used by the routing system to forward
   packets from a sending node on an origin subnetwork to one or
   more receiving nodes on one or more destination subnetworks."
5.1
"However, ILNP supports
   graceful changes in L values, and this is explained below in Sec
   XXXX in the discussion on mobility support."

Section 6 - there appears to be something strange going on with the subsection numbering - there is a 6, a 6.1, then a sub 6.1 underneath it which I think should probably be 6.1.1

6.1.1 -
I believe that this
"2) soft handover: the host sends Locator Update (LU) messages
        to CNS, but it uses both L_A and L_B until (i) it longer"
was intended to read "it no longer..."

Also, several of the informative references in both this document, ilnp-icmpv4 and ilnp-eng seem to be incomplete, holding only the RFC number (no metadata).

Lastly, the Table of Contents for both the above-referenced drafts, ilnp-v4opts, and ilnp-arp, seems to be incomplete/placeholder.


Regarding ilnp-noncev6 -

Section 3 says that this may likely be the only option in the packet - is there any consideration for option ordering if it is *not* the only option? Eg should it always be first to aid in processing, etc?

Also, Sections 6 and 7 deal with handling packets in various permutations where the nonce is and is not present based on the compatibility of the node with ILNP. However, I do not see any text that is similar to the following from ilnp-v4opts: "This IP option MUST NOT be present in an IPv4 packet unless the
   packet is part of an ILNPv4 session.  ILNPv4 nodes MUST include
   this option in the first few packets of each ILNP session, MUST
   include this option in all ICMP messages generated by endpoints
   participating in an ILNP session, and MAY include this option in
   all packets of an ILNPv4 session."
And elsewhere: "[same text as above] + It is RECOMMENDED to include this option in all
   packets of the session if packet loss higher than normal."
The concept is covered, but I think that this text is more succinct in covering the requirement, and I recommend that something similar be added to noncev6, and possibly ilnp-icmpv6.

Regarding ilnp-v4opts -

The security considerations section is missing any discussion about IP Options similar to what is present in ilnp-noncev6: " As this is an option within the IPv6 Destination Option Header,
   rather than an option within the IPv6 Hop-by-Hop Option Header,
   the presence of this option in an IPv6 packet ought not disturb
   routers along the path an IP packet containing this option
   happens to travel.  Further, many deployed modern IP routers
   (both IPv4 and IPv6) have been explicitly configured to ignore
   all IP options, even including the "Router Alert" option, when
   forwarding packets not addressed to the router itself."

I'm also wondering if there should be one or more informative references in the security considerations for both noncev6 and v4opts regarding the handling of IP Options, both to back up the assertion that ignoring IP options is common practice to avoid DoS attack vectors, and also to give the reader additional resources as to current BCP when it comes to routers beyond the core of the network - eg draft-gont-opsec-ip-options-filtering, etc.

Thanks,

Wes George


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Tony Li
> Sent: Saturday, January 14, 2012 1:57 PM
> To: [e-mail]
> Cc: Lars Eggert
> Subject: Re: [rrg] Last call for revised ILNP documents [Corrected]
>
>
> Whoops.  There are 9 documents in the full set.   The other two are:
> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-arch-00.txt
> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-eng-00.txt
>
> Thanks to Dae Young Kim for noticing my goof.
>
> Please note that the consensus check description on doodle.com has a
> scalability issue and cannot support the full links for all documents.  I've
> reduced that to just use document filenames.
>
> Missed it by that much,
> Tony
>
>
> On Jan 14, 2012, at 10:18 AM, Tony Li wrote:
>
> >
> > Hi all,
> >
> > I'm very pleased to announce that after an extended duration, the ILNP
> documents have been modified to address IRSG review comments.  There are now 7
> documents in the full set.  Links to the documents are here:
> >
> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-icmpv6-00.txt
> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-icmpv4-00.txt
> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-v4opts-00.txt
> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-dns-00.txt
> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-noncev6-00.txt
> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-adv-00.txt
> > http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-arp-00.txt
> >
> > Given the extent of the changes, it's appropriate that the RG review and
> comment, with a full two week review cycle and consensus check.
> >
> > The consensus check can be found here:
> http://www.doodle.com/zfvazx94shuhei5d
> >
> > Please read, comment and respond to the consensus check by 12:00 noon, PST
> Jan 28, 2012.
> >
> > Thanks,
> > Tony
> >
> >
>
> _______________________________________________
> rrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.