Subject: RE: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt

From: "Elwyn Davies" <[email-masked]>
Date: Mon, 5 Aug 2002 14:32:21 +0100

Hi.

I had also been thinking about this matter, in particular in relation to
routers having to advertise exactly matching prefix lengths to go with the
hosts' chosen IID length for stateless autoconfig.

Further comments below...

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: 05 August 2002 01:41
> To: [email-masked]
> Subject: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt
> 
> 
> 
> As mentioned on this list previously, the IPv6 WG has been asked
> to review draft-savola-ipv6-127-prefixlen-04.txt, which has been
> submitted to the RFC editor for publication as an Informational
> RFC.
> 
> The draft discusses several operational issues with the use of /127
> prefixes on point-to-point links between routers.
> 
> Reviewing this draft raised several interesting questions, in my
> mind, about our current addressing architecture... 
> 
> First, I wondered why this would be an issue when all recent versions
> of the Addressing Architecture, including the most recent update 
> (draft-ietf-ipngwg-addr-arch-v3-08.txt) specify a maximum length 
> prefix of /64 for all addresses that don't start with '000'.  At 
> least, this is clearly implied by the following wording:
> 
> "For all unicast addresses, except those that start with binary 
> value 000, Interface IDs are required to be 64 bits long and to be 
> constructed in Modified EUI-64 format."
> 
> Unfortunately, operators seem to be ignoring this restriction in
> numbering point-to-point links between routers.  I have spoken to 
> a few IPv6 operators, and it is common practice to use /125, /126
> or even /127 prefixes for these links.
> 
> What does this mean for us?  Well, in my opinion, we don't want
> to standardize a restriction that we _know_ will be ignored by
> the folks who are deploying the software.
>    
> We want/need to use EUI-64-based addresses for address 
> autoconfiguration.  But, is this inherently incompatible with
> the folks using longer prefixes on point-to-point links?  Why
> do all IIDs need to be in modified EUI-64 format?  Do we
> want to remove this restriction from the addressing architecture?
> Or can we show good reasons why it shouldn't be ignored?

Two totally unrelated points here:
-  Coordination of prefix lengths and IID lengths between routers and hosts
in stateless autoconfig becomes more complex.  At present we would just
assume 64 each.
-  Whilst it is undesirable to artificially restrict what is possible
because of what is currently 'easy' in hardware, knowing that a significant
(or even the majority) of prefixes are guaranteed to be no more than 64 bits
in length would allow part of forwarding tables to be built with only half
the memory and with today's top end general purpose processors the
processing can be carried out in one register.  Given that the removal of
strict hierarchical allocation for techno-political reasons is likely to
result in continued expansion of the DFZ forwarding table size, savings in
both storage and processing time are probably worthwhile.  I haven't seen
any analysis of the savings that knowing a significant fraction of the table
would be for 64 bit maximum prefixes.

On the other hand, singling out the EUI-64 format as the sole (standardised)
IID format does not cater for all evntualities.  Other formats may become
useful. 
> 
> We also may want to be cautious about standardizing mechanisms 
> that rely on a hard /64 boundary between the prefix and IID.
> For example, what is the minimum number of IID bits I must 
> have to use privacy addresses?
>
If IIDs other than 64 bits are available, consideration should be given to
encoding the length of the IID in the address prefix.  This allows various
sanity checks to be done and potentially reduces the amount of knowledge
needed for autoconfig.  Routers could check that prefixes advertised were
not longer than the maximum implied by the IID length, and stateless
autoconfig could verify that the prefix was of the right kind to match with
a particular IID, and (with a little additional work) routers could identify
what sort of prefixes were needed.

Assuming backwards compatibility is needed, prefixes starting 001 binary
would be assumed to be 64 bit prefixes as at present.  It would probably be
appropriate to release another portion of the reserved address space for the
explicitly encoded IID length prefixes. 
> 
> The addressing architecture also imparts special meaning to two 
> bits in the middle of the IID.  Bits 70 and 71 of an IPv6 address 
> are called the 'u' bit and the 'g' bit, and their semantics are 
> based on the meanings of the corresponding bits in EUI-64 
> identifiers (with the sense of the 'u' bit reversed).  The
> 'u' bit is supposed to indicate whether the IID is a globally
> unique EUI-64-based identifier (1=yes, 0=no), and the 'g' bit
> is reserved (must be 0).  When longer prefixes are used, though, 
> these bits end-up in the prefix, instead of in the IID.
> 
> Can we really expect operators to reserve these two bits for
> this use?  Or will they allocate their longer prefixes without
> worrying about the meaning of these two bits?
> 
> If we think that, in practice, operators will ignore the meaning
> of these two bits, does the 'u' bit really have any meaning at all?
> 
If the subset of address prefixes that go with 64 bit EUI-64 IIDs are
identifiable, then we can continue with the special interpretation of the g
and u bits.  Operators can allocate their longer prefixes out of a different
set that is allowed to have /127 prefixes.

> Do I have any answers to all of the questions I keep asking? :-)
> Well, maybe...
> 
> In my opinion, we should not standardize a hard boundary between
> the prefix and the IID, especially if we know it will be ignored
> by operators.

As long as we know where the boundary is.

> 
> We can make it clear that a 64-bit boundary is required in order
> to use EUI-64-based addresses for address autoconfiguration.  And,
> it might make sense to document a maximum prefix length that is
> consistent with privacy addresses.
> 
> I also think that we should drop the 'u' and 'g' bit semantics
> from the addressing architecture.  It is pretty clear, at this
> point, that we won't ever be certain that an address with the 
> 'u'-bit set has a globally unique IID, so there really isn't
> any reason to clutter up the addressing architecture with these
> strange bits.

Once it is known what the length of the IID is, we can keep the semantics of
the u and g bits if we want but it becomes much less of an issue if it is no
longer the only way and also there should be no chance of confusion (if the
prefix starts 001 binary, prefixes longer than /64 should be discarded and
never used to form addresses).  The semantics of the EUI-64 could be
separated out and put in a separate draft to emphasise this.
> 
> What do the rest of you think?
> 

My twopennorth'

Elwyn Davies

> Margaret
> 
> 
> 
> 
> 
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------
>

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 6 Aug 2002 14:00:22 -0700

> From: Pekka Savola [mailto:[email-masked]]
[...]
> If you know an address, and be able to "guess" the prefix length (ie:
> assume /64), this opens quite a few possibilities for all kinds of
> specifications.

For example, the reserved subnet anycast addresses (such as the
subnet router anycast address) become much more useful.

For example, instead of having to use a RouterAlert option, you could
make an IPv6 multicast traceroute (see
http://www.dante.net/mbone/refs/draft-ietf-idmr-traceroute-ipm-07.txt
for the IPv4 spec) that uses the subnet router anycast address, and
not burden other routers with HbH processing.

-Dave

---

From: "Michel Py" <[email-masked]>
Date: Wed, 7 Aug 2002 23:28:28 -0700

Pekka,

> Pekka Savola wrote:
> This is incorrect; there are two issues here:
> 1) addrarch statements about /64 which make the use of
> longer than /64 "forbidden"
> 2) people still using /127 and in future experiencing
> problems due to  subnet router anycast address.
> The point of my draft has *ALWAYS* been 2).  It's not
> an advocacy document (point 1) above), even though people
> have tried to make it one (and I must admit I've given
> in an inch or two).

This is a good point, please allow me to rephrase:
*if* [addrarch] was to be modified to make prefixes longer than /64
"legal", you would then have to modify your draft to remove issue #1.
Although issue #2 is perfectly valid and I will gladly support it *if*
it does become issue #1, the fact of the matter is, as Margaret pointed
out, your draft does bring a policy issue.

So, whether you like it or not, your draft is an advocacy document. What
I should have said is:

- If [addrarch] is to be modified, you are looking at a major re-write.
- If [addrarch] is *not* to be modified, your draft is fine as-is.

Hope this makes sense.
Michel.

---

From: "Michel Py" <[email-masked]>
Date: Wed, 7 Aug 2002 23:48:16 -0700

Thomas,

>> "For all unicast addresses, except those that start with
>> binary value 000, Interface IDs are required to be 64 bits
>> long and to be constructed in Modified EUI-64 format."

> Thomas Narten wrote:
> If anyone thinks this is still an issue, it would be good to
> point out the specific text that is believed to be unclear
> and suggest replacement wording.

I do not suggest replacement wording as the one quoted >> above is clear
to my poor English.

If I may, it appears to me that the issue currently being discussed is
about the [addrarch] text being flawed, not being unclear.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Aug 2002 08:42:46 -0700

Margaret,

> Margaret Wasserman wrote:
> The current situation with the addressing architecture is that
> we have established a consensus of the WG to make two changes
> to the document (described in Bob's mail) and send it (back)
> to the IESG for consideration as a draft standard.
> I have not seen a level of response to this thread that would
> lead me to question that consensus. Have you?

No. My opinion is that the draft should be sent back to the IESG, and I
apologize if I have contributed in delaying that. Ship it, by all means.

Back to the issue at hand, before you got us into that swamp, the topic
was about draft-savola-ipv6-127-prefixlen-04.txt.

IMHO, there are two ways to look at Pekka's draft:

1. It is irrelevant, as /127 prefixes are not supposed to exist anyway.

2. OTOH, the use of /127 is widely spread and I peer with two pTLAs
using /127s myself.

So the question indeed is do we want an RFC that remotely suggests that
there are alternative ways to what [addrch] says, although it does
provide some insight into legacy practices.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 12 Aug 2002 13:37:03 -0700

Thomas,

>> Michel Py wrote:
>> Note about this: My reading is that there still is a
>> semi-hard boundary at /48, (site) and I think this is good.

> Thomas Narten wrote:
> If you are talking about addrarch, please point out the
> words that lead you think this. There is *no* technical
> hard boundary at /48. There is a *policy* or *allocation*
> boundary, and there are technical reasons why such a boundary
> make sense,

I was talking about the policy part, see below.

> but implementations should not have any sort of /48 boundary
> hard-wired into the code.

Agree.

> Right now, End sites can expect to get a /48,

This is what I called earlier a semi-hard boundary. Not part of the
Addressing Architecture, but assumed by many nevertheless.

> and they get use the 16 bits between a /48 and /64 anyway
> they care. If a site switches providers, it knows it will
> get 16 bits again, and it konws that it needs to (only)
> renumber the upper 48 bits. This is both simple and powerful.

Yep, and the same reasoning also applies to 6to4, so people that have
choose to use 6to4 as a short-term mechanism will also greatly benefit
from the fact that a site, although not defined in [addrarch], is also a
/48.

>> But, what I think this WG needs to think about and understand
>> is _why_ operators are using longer prefixes on their
>> router-to-router links.

> This is a key question. Just because operators are doing this,
> doesn't mean they should or that we should just give in and say
> "I guess we should give in to reality".

"Just because _some_ operators are doing it" seems more appropriate to
me. 

Especially on the 6bone, private discussions I had with them have shown
that the use of /127s is mostly a post-cidr v4 withdrawal, and most of
them would gladly renumber all their ptp links, if only they had more
time.

I agree with the rest of your postings.

Michel.

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 13 Aug 2002 11:49:01 -0400

I want to see more discussion and I believe Thomas and Tony have raised valid points.

I also think this fix should solve with wording plugging two networks together. That I am thinking on how we word it.  But if we are to do DAD on all bits then we can also add that when a network joins another then DAD must be done by one of them.

But if all do dad on the link-local and EUI then that would work to and with the optimization many of us implementors used I am wondering if we still have the problem for a "node".  

The issue is for two separate nodes and I think the wordage bob sent out killed that and what I perceived steve to be arguing at Yokohoma where there was no consensus I saw as follows:

Node 1 has EUI of X'c3de'
Node 2 has EUI of X'c3de'

That we would permit Node 1 to be 4ffe::c3de and Node 2 to be 3ffe::c3de 

But the words I read from Bob would not permit this?  That is the heartburn I have big time.

I believe that we all agreed that EUI could be duplicated by manufactures and we should prevent that as best we can with DAD.

Also Thomas is correct silence has in other working groups been used to state consensus cannot be determined.  My opinion is that if working group members don't respond by some amount of time then too bad they loose and we move forward.  But that is not how things are being managed out of IPv6 WG in some cases and I would prefer we adhere to the same policy in all working groups in the IETF.  Possibly this is an issue for the chairs to discuss with ADs to get some consensus on the state of the IETF and get a decision.

regards,
/jim

> From: Robert Elz [mailto:[email-masked]]
> Sent: Tuesday, August 13, 2002 10:58 AM
> To: Margaret Wasserman
> Cc: Michel Py; [email-masked]
> Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt 
> 
> 
>     Date:        Mon, 12 Aug 2002 09:31:08 -0400
>     From:        Margaret Wasserman <[email-masked]>
>     Message-ID:  <[email-masked]>
> 
>   | The current situation with the addressing architecture is 
> that we have
>   | established a consensus of the WG to make two changes to 
> the document 
>   | (described in Bob's mail) and send it (back) to the IESG 
> for consideration 
>   | as a draft standard.
> 
> From where did we get that consensus?   We're still discussing the
> two changes, it is clear that Tony Hain at least (maybe Jim 
> Bound, that's
> less clear) is opposed to one of them.   But in general most seem to
> support making those changes.
> 
> Though that's mostly by silence - and if you believe one of Thomas'
> recent messages, silence is not enough to change the status quo ...
> (which here would be what is in addrarch-08).
> 
> I don't, I think if there's support, and no stated technical 
> objections,
> then changes should be made, if the silent majority see that 
> coming and
> disagree, they won't remain silent.
> 
>   | I have not seen a level of response to this thread that 
> would lead me to 
>   | question that consensus.  Have you?
> 
> I haven't seen anything in this thread that establishes any 
> consensus for
> sending the doc back to the IESG yet at all.
> 
> kre
>

---

From: "Michel Py" <[email-masked]>
Date: Fri, 16 Aug 2002 11:04:50 -0700

kre,

> Name one operational annoyance?   That is one that my use of
> /112 (or someone else's use of /126 or /127) inflicts upon you,
> assuming that you're not the other end of the link (if you are,
> it is your choice to participate, no-one is compelling you to
> use > /64).

I will address this in a reply to jj later.

> then it really starts to look as if the only reason for
> not changing is stubbornness.

About which you and I are renowned world-class contestants ;-)

> Maybe I wasn't clear enough that the 'u' but is the worst
> part of the draft. It (or the part of it which pretends
> to be visible externally) is the thing which most needs
> to be deleted. I don't just want it gone in order that the
> 64 bit boundary can go, I want it gone because it is
> unimplementable nonsense, which doesn't belong in the doc.

I understand the point you are trying to make, but I fail to understand
the urgency. Part of your procedural argument before was that the 'u'
bit was not implemented and therefore should be deleted. I disagree with
the phrasing; I would much rather say something like it is implemented
but not used.

Correct me if I'm wrong, but I think the point you are trying to make is
"Let's remove this 'u' bit before someone finds a nasty/dirty use for
it".
Without a context, I would agree with you, but you can't ignore the
bigger picture.

Since you are one of the persons who understand the details of the
mechanisms behind MHAP and the differences with GSE, I hope that you
also understand clearly that there is currently nothing in what ipv6mh
is doing that suggests this.

That being said, the reason I don't see the urgency of removing the 'u'
bit is that it seems to me that the only use that could be made of it
would be a descendant of GSE. If that does not happen, removing the 'u'
bit in three years would not be more difficult nor more work than it is
today.

OTOH, considering the less-than-perfect status of IPv6 multihoming
today, if Mike O'Dell or one of his heirs comes with a breakthrough that
addresses the documented shortcomings of GSE, the 'u' bit is likely to
be re-instated even if we remove it now; that would likely bring a whole
new set of issues.

In other words, the pros and cons about removing the 'u' bit are:
Pros: If we remove it, nobody will invent something nasty that uses it.
Cons: If we remove it, nobody will invent something nice that uses it.

IMHO, it is a lot easier to kill a nasty project than to remove
roadblocks in the way of a nice one.

Michel.