Subject: 6MAN WG Last Call: <draft-ietf-6man-prefixlen-p2p-00.txt>

From: Bob Hinden <[email-masked]>
Date: Thu, 18 Nov 2010 16:34:45 -0800

All,

This message starts a 6MAN Working Group Last Call on advancing:

	Title           : Using 127-bit IPv6 Prefixes on Inter-Router Links
	Author(s)       : M. Kohno, et al.
	Filename        : draft-ietf-6man-prefixlen-p2p-00.txt
	Pages           : 9
	Date            : 2010-10-15

       http://tools.ietf.org/html/draft-ietf-6man-prefixlen-p2p-00

as a Proposed Standard.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on December 6, 2010.

Regards,
Bob Hinden & Brian Haberman
6MAN Chairs

---

From: Randy Bush <[email-masked]>
Date: Fri, 19 Nov 2010 09:18:29 +0100

as a confessed co-author, i susppor this document advancing.  i mention
this because there are documents which i have co-authoeed which i did
not support.

randy

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Nov 2010 12:07:54 +0200 (EET)

On Thu, 18 Nov 2010, Bob Hinden wrote:
> as a Proposed Standard.  Substantive comments and statements of 
> support for advancing this document should be directed to the 
> mailing list.  Editorial suggestions can be sent to the authors. 
> This last call will end on December 6, 2010.

I think the document needs work before it can be progressed. I do 
think this is a useful document (esp section 5.1 and 5.2).

The document should probably mark in its header RFC3627 obsolete, and 
mark itself as updating RC4291 (in practise Section 6 appears to do 
so).

Section 3, second paragraph does not reflect operational reality:

    For the purposes of this document, an inter-router point-to-point
    link is a link to which only two routers and no hosts are attached.
    This may include Ethernet links which are configured to be point-to-
    point.  In such cases, there is no need to support Neighbor Discovery
    for address resolution, and other general scenarios like the use of
    stateless address autoconfiguration are not relevant.

.. Please educate me on implementations that allow you to configure 
Ethernet link as point-to-point (in ifconfig IFFLAGS sense).

Section 4 does not describe the root cause (i.e. why /127 can be used 
successfully) i.e. that Subnet-router anycast addresses have not been 
implemented, or if they have been implemented, it has been done only 
with prefixlen=64 (similar to what was suggested in RFC3627 point 4):

4. Problems identified with 127-bit prefix lengths in the past
..
    Though the analyses in the RFCs are correct, operational experience
    with IPv6 has shown that /127 prefixes can be used successfully.

Section 6 should probably be renamed "Conformance" instead of 
recommendations (it's giving out MUST advice etc.)

I think there will be pushback on the brief security considerations 
section.

I think the document could be clearer wrt terminology of 
'point-to-point'.  In some context it means a link where there should 
be only two nodes connected.  In some contexts it means a link which 
by its nature can only have two nodes connected and does not perform 
neighbor discovery.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Nov 2010 10:28:15 +1300

Ship it. Long overdue, and good enough.

Regards
   Brian Carpenter

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 19 Nov 2010 17:13:31 -0500

I agree with the prior comment that the document should explicitly state 
that it obsoletes RFC 3627 and updates RFC 4291.  Otherwise, I support 
advancing the doc.

On 11/18/2010 7:34 PM, Bob Hinden wrote:
> Bob Hinden&  Brian Haberman
> 6MAN Chairs
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Randy Bush <[email-masked]>
Date: Sat, 20 Nov 2010 06:50:56 +0100

> I agree with the prior comment that the document should explicitly
> state that it obsoletes RFC 3627 and updates RFC 4291.

you missed the discussion about that?

randy

---

From: Shane Amante <[email-masked]>
Date: Sat, 20 Nov 2010 02:50:19 -0700

I support publishing of this WG doc as a Proposed Std.

-shane

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Nov 2010 09:52:29 +1030

(a) is link local addressing required/supported on these types of
links?

(b) if so, what is their prefix length?

(c) if so, how are the IIDs automatically determined/derived?

(d) if ND is switched off on multi-access technology (e.g. ethernet)
point-to-point links, as the draft says it can be, how are neighbor
cache entries for the remote layer 3 to layer 2 address mappings
created? Manual? Promiscuous mode on the receiving end?

(e) How is the situation that one end switches off ND but the other end
doesn't handled?

(f) if ND is switched off, how is DAD and/or NUD performed on the
addresses? Link state can't be assured to be a NUD indicator on
multi-access links, and DAD would be useful to prevent IID collisions
when there is a 50:50 chance of getting it wrong.

(g) IPV6CP uses IID of zero to indicate an unset IID, to which the peer
will respond with a suggested non-zero IID -

"  If the two interface identifiers are different but the received
   interface identifier is zero, a Configure-Nak is sent with a non-zero
   interface-identifier value suggested for use by the remote peer.
   Such a suggested interface identifier MUST be different from the
   interface identifier of the last Configure-Request sent to the peer."

How is that supposed to now work when /127s create ::0 IIDs?

On Thu, 18 Nov 2010 16:34:45 -0800

---

From: Miya Kohno <[email-masked]>
Date: Sun, 21 Nov 2010 21:42:05 +0800

Hi Mark,

 (a)-(c): 
Link local is orthogonal in this topic. This document does not address
it. 

 (d)-(f):
Static IPv6 neighbor has been used occasionally. There are quite a few
sources which describe it, so please refer to them. 

 (g):
This document didn't go any further into the definition of IID. But it
did prevent addresses with all zeros in the rightmost 64 bits.

Thanks,
Miya
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Mark Smith
> Sent: Sunday, November 21, 2010 8:22 AM
> Cc: 6man Mailing List
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-prefixlen-p2p-00.txt>
> 
> 
support
> for advancing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the authors.  This last call will
end
> on December 6, 2010.

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Nov 2010 07:47:58 +1030

Hi Miya,

I don't find your answers acceptable I'm afraid, but aren't willing to
spend any more of my time addressing them. Even though I disagree
with /127s in principle, my secondary goal of trying to ensure this
standards-track ID, if published, wasn't ambiguous, vague and
conflicting with other standards track IPv6 RFCs also seems to be a
lost cause.

Regards,
Mark.

On Sun, 21 Nov 2010 21:42:05 +0800

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 22 Nov 2010 14:27:19 +0000

In general, I support advancement of this draft, since it is largely
documenting an existing practice, but I think that Mark brings up a few
points that should be incorporated as clarification in the draft. More
comments below inline

Wes George

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Miya Kohno
> Sent: Sunday, November 21, 2010 8:42 AM
> To: Mark Smith
> Cc: 6man Mailing List
> Subject: RE: 6MAN WG Last Call: <draft-ietf-6man-prefixlen-p2p-00.txt>
> 
> Hi Mark,
> 
>  (a)-(c):

[WES] Then my recommendation would be to explicitly state this in the
document. Perhaps something specifying that this document only discusses use
of /127 for global scope IPv6 space, and link-local /127 links is out of
scope for the document.
> sources which describe it, so please refer to them.

[WES] No, you should have informative references to them in the document
rather than leaving the reader to infer/find them. And specifically for D
and E, you need to provide some guidance to implementers on what should be
done in these cases.

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Nov 2010 10:56:04 -0500

excuse bad email form.  this is an ipad.
randy

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Nov 2010 10:56:52 -0500

---

From: Randy Bush <[email-masked]>
Date: Mon, 22 Nov 2010 11:04:25 -0500

> of /127 for global scope IPv6 space, and link-local /127 links is out of

the list of things which are orthogonal or out of scope is exceedingly large.  perhaps we do not want to start enumerating it. 

> and E, you need to provide some guidance to implementers on what should be

ibid

can we focus on the doughnut, not the hole?  you wanted to push this through now, as opposed to cleaning up details such as full CIDR. if we are to be drawn into the whirlpool, the I would like to put that in, depricate subnet  nevercast, ... are you sure you really want to unravel this?

Randy, fighting with the ipad's MUA

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Mon, 22 Nov 2010 17:45:42 +0000

From: Randy Bush [mailto:[email-masked]] 
Sent: Monday, November 22, 2010 11:04 AM
To: George, Wes E [NTK]
Cc: Miya Kohno; Mark Smith; 6man Mailing List
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-prefixlen-p2p-00.txt>

[WES] Within reason, I agree. This isn’t meant to be a compendium of everything the document does not talk about, and I wasn't asking for it (nor was anyone else AFAIK). However, I don’t think it’s too much to identify this specific item as out of scope since the question was already asked.

[WES] Asking for some clarification in the document to address legitimate ways that this may break and answer questions posed by a reviewer is not unraveling it. My comments in Beijing referred to being opposed to expanding the scope of this document to handle other sizes of address blocks, mainly because I don’t believe that the argument to do that is nearly as compelling nor as easy to gain consensus on, and I want to choose my battles. No, I don’t want to see this delayed with a bunch of minutae and nits that don't ultimately improve the document, but the reason I highlighted a couple of things Mark said is that I’m not convinced that these are all minutiae and nits.

Wes George

---

From: Miya Kohno <[email-masked]>
Date: Tue, 23 Nov 2010 20:40:54 +0800

Hi Wes, all,

> document. Perhaps something specifying that this document only
discusses
> use

In the "3. Scope of the Memo" section, it says "this document is
applicable to cases where operators assign specific addresses on
inter-router point-to-point links and do not rely on link-local
addresses. 

In order to make it explicit, we will state that link local is out of
the scope of the document. 

> and E, you need to provide some guidance to implementers on what
should be

The "no need for ND" was an extreme case example and we didn't mean to
recommend it in general. So we don't want to provide a specific guidance
for this case.

Let us remove this to avoid confusion. 

Thank you for your feedback. We will modify the points above in the -01
version.

With regard to the recommendation in other thread to update/obsolete
RFC3627, we'd defer to the chairs.

Regards,
Miya

> > > (e) How is the situation that one end switches off ND but the
other
> > > > 	Title           : Using 127-bit IPv6 Prefixes on
Inter-Router
> > > Links
> > > > Bob Hinden & Brian Haberman
-------------------------------------------------------------------
> > -
> > > > Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6
-------------------------------------------------------------------
> > -
> > > Administrative Requests:
https://www.ietf.org/mailman/listinfo/ipv6