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: [email protected] [mailto:[email protected]] On Behalf Of Tony Li
> Sent: Saturday, January 14, 2012 1:57 PM
> To: [email protected]
> 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
> [email protected]
> 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.
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
