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

From: "Michel Py" <[email-masked]>
Date: Fri, 9 Aug 2002 21:18:01 -0700

kre,

What you are calling for (quoted below) is lots of changes. With that
many deletions, one might say that it could be wiser to re-write
[addrarch] entirely.

Note that I don't oppose the idea and I acknowledge that you do have
very good points, but WRT what Margaret mentioned earlier about
consensus, do you think you can rally the WG behind these proposed
changes?

Michel.

-----Original Message-----
From: Robert Elz 
Sent: Tuesday, August 06, 2002 3:27 AM
To: Thomas Narten
Cc: Margaret Wasserman; Elwyn Davies; [email-masked]
Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt 

    Date:        Mon, 05 Aug 2002 16:06:45 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | They better not be doing this. We have been over this territory a
  | number of times already, with some folks arguing only a misreading
of
  | the spec would allow one to conclude that prefixes cannot be longer
  | than /64,

There's no need to argue this (any more anyway), there are any number
of messages on this (I think) and certainly other (like the 6bone) lists
which state that as an absolute incontrovertible fact (no prefix length
longer than 64 is allowed) - and quote the addr arch doc (and the latest
draft) as justification.

We really need to fix that - and also get rid of the other odds and ends
in that draft thats imply make no sense when prefixes longer than 64
are being used.

  | 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.

OK (though I'm not sure "unclear" is the right description)...

All this relates to draft-ietf-ipngwg-addr-arch-v3-08.txt naturally
(the version dated June 29, 2002, so I believe it is the most current).

The para (near the end of page 8):

   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.

should simply be deleted.   No replacement required.

Then the last line on page 8, and continuing into page 9:

   Modified EUI-64 format based Interface identifiers may have global
   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
   IEEE EUI-64 identifiers) or may have local scope where a global token
   is not available (e.g., serial links, tunnel end-points, etc.) or
   where global tokens are undesirable (e.g., temporary tokens for
   privacy [PRIV]).

should also be deleted.  No replacement is required.

Then, next paragraph

   Modified EUI-64 format interface identifiers are formed by inverting
   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
   forming the interface identifier from IEEE EUI-64 identifiers.  In
   the resulting Modified EUI-64 format the "u" bit is set to one (1) to
   indicate global scope, and it is set to zero (0) to indicate local
   scope.  The first three octets in binary of an IEEE EUI-64 identifier
   are as follows:

Delete the 2nd sentence, no replacement required.   That leaves...

   Modified EUI-64 format interface identifiers are formed by inverting
   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
   forming the interface identifier from IEEE EUI-64 identifiers.  The
   first three octets in binary of an IEEE EUI-64 identifier are as
follows:

Then, lower down on page 9, the paragraph

   The use of the universal/local bit in the Modified EUI-64 format
   identifier is to allow development of future technology that can take
   advantage of interface identifiers with global scope.

should simply be deleted.  No replacement is required.  This is perhaps
the worst of everything in the draft, no matter what happens to the
rest,
that paragraph simply has to be deleted.  This is the "we have no idea
what we're going to do with this, but we are going to define it anyway"
(and while doing so, ignore the fact that lots of people are ignoring
us)
approach.

Next, at the end of page 10 (sect 2.5.4) spanning onto page 11 ...

   All global unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in section 2.5.1.  Global unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

should simply be deleted.   No replacement is required.   The paragraph
following that one would then look rather out of context (though nothing
it contains is objectionable), so I would delete that one as well, it
isn't required for anything.

The rest of the draft is all very careful to express things in terms
of variables (n m etc) and is all fine.

  | However, it is true that there are some places where /64 is in fact
  | not changable in practice (without very significant upheaval in
  | well-established documents). You cannot do stateless addrconf on an
  | Ethernet (or FDDI, or any other typical LAN) with a prefix other
than
  | /64.  I view this as a reasonable engineering compromise between an
  | number of tradeoffs (but won't attempt to list them here).

Absolutely.   That's just fine, and I don't think anyone is suggesting
changing that.

If you know that the link is an ethernet (etc), then you are going to
have a
pretty good idea that the prefix length is 64.   But if you have no idea
what kind of link an address happens to be connected to (so you are
clearly
neither the node owning the address, nor connected to the same prefix,
nor
the local network manager) then why should you care?

Eg: munnari.oz.au's IPv6 addr (the advertised one anyway) is

	2001:388:c02:4000::1:21

Do you want to guess what kind of link that is connected to, and what
its
prefix length happens to be ???   Is there any rational reason at all
that
you're ever going to care?

kre

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

--------------------------------------------------------------------
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: Bill Manning <[email-masked]>
Date: Fri, 9 Aug 2002 21:41:20 -0700 (PDT)

well Michael, the wg has a choice:

	proceed w/ the arch doc as defined, disenfranchising operators
		and the spirit of the original design goals.
	or.
	make changes to the arch doc based on operational experience.

one choice will keep the IETF work relevent to operations, the other choice
less so.

--bill

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Aug 2002 17:01:49 +0700

Date:        Fri, 9 Aug 2002 21:18:01 -0700
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | What you are calling for (quoted below) is lots of changes. With that
  | many deletions, one might say that it could be wiser to re-write
  | [addrarch] entirely.

No, I don't think that's true, I think it is actually just moving it
back to an earlier version - just from reading it it is obvious that the
magic "64" has been grafted in later (we have diagrams that use m, n, etc,
and then some text says "m + n = 64" - and it isn't as if that's a just
a style issue, when the value is "128" (which is a fixed constant of course)
the diagrams say "128 - n").

The changes are relatively minor, and affect nothing at all about the
way that v6 works, or is used, or is currently deployed, or ...

Note: to go to DS we have to provide evidence of at least two independent
implementations of every feature of the doc.  Any that aren't actually
implemented are required to be removed (perhaps to another doc to recycle
at PS, but more often to experimental or just the vast emptiness of space).

Where are the implementations of the 'u' bit implying global uniqueness?
Where are the implementations requiring /64 everywhere, everytime?

If they don't exist, the IETF's rules require this stuff to be removed.

  | Note that I don't oppose the idea and I acknowledge that you do have
  | very good points, but WRT what Margaret mentioned earlier about
  | consensus, do you think you can rally the WG behind these proposed
  | changes?

I have no idea.   That's not easy to judge, especially when most of what
I assume to be the part of the WG that doesn't want these changes is just
saying nothing.

What I'd like to see if for someone who actually believes the doc should
remain as it is, could actually explain the reasons why.   Part of the
problem that this is so frustrating, is that no-one seems willing to
actually explain what we're getting from these requirements.

Even a pointer to an older thread on the list where this was discussed and
the reasons given would do (Subject headers and approx date would be great).

Without that, the impression is that everyone is just silently agreeing
(other than those who say that the draft can't change because it already
exists) with the points being made, but I am pretty sure that's not the
case.  But I have no idea at all why.   Maybe someone can convince me that
there's actually some benefit that I just can't see.

As I recall, the only argument I've ever heard, is that the 'u' bit is
important, because sometime in the future someone might come up with some
scheme that will allow these "globally unique" IIDs to be treated specially
for some purpose or other.    And even though that's just wild speculation,
I could almost buy that (I'm one of the people who doesn't mind making 
allowances for things that might happen in the future in general, even if
we don't know what they are) - except that no-one has been able to tell me
how we would ever cope with devices that simply have no idea if their
MAC address is globally unique or not (and so really, in this interpretation
would have to always leave the 'u' bit clear in all addresses - I can
easily show that KAME would be broken according to this interpretation for
example - that is, I can have it autoconfigure addresses with the 'u' bit
set where the IID isn't globally unique - and I certainly can't imagine
a way the KAME people could fix it, other than by never setting 'u'), and
perhaps more importantly, as that one can always be hand waved away as a
"configuration error" (though the imaginary protocol using this would have
to deal with it, somehow) how we deal with address stability when a MAC
address changes, so the IPv6 address is no longer based upon an EUI-64,
though it used to be.

So, let me turn the question around.  Is there anyone out there who believes
the draft should stay as it is (in this area) and who is willing to attempt
to explain why?

If there's no-one, then to me that looks like consensus for a change...

kre

---

From: Thomas Narten <[email-masked]>
Date: Mon, 12 Aug 2002 16:05:08 -0400

> address changes, so the IPv6 address is no longer based upon an EUI-64,

You seem to be wanting to require that if the u-bit is set, it is
*guaranteed* to be globally unique. No one can make such a guarantee,
of course. I have always viewed the  u bit a way of indicating that
the IID is probably unique, with  a high degree of likelyhood. This is
achieved by setting the u bit to 1, iff the ID is derived  from an
IEEE identifier.

> the draft should stay as it is (in this area) and who is willing to attempt

I've tried to do so in another note.

> If there's no-one, then to me that looks like consensus for a change...

Not so fast. To change the status quo, one needs more than just a
couple of people saying "yes" and the vast majority of the community
being silent.

Thomas

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 21:15:16 +0700

Date:        Mon, 12 Aug 2002 16:05:08 -0400
    From:        Thomas Narten <[email-masked]>
    Message-ID:  <[email-masked]>

  | You seem to be wanting to require that if the u-bit is set, it is
  | *guaranteed* to be globally unique. No one can make such a guarantee,
  | of course.

No, as I just said in another reply, I'm trying to figure out how the
IID can possibly be used (depending on any uniqueness property) when we
know that that can't happen.

  | I have always viewed the  u bit a way of indicating that
  | the IID is probably unique, with a high degree of likelyhood. This is
  | achieved by setting the u bit to 1, iff the ID is derived  from an
  | IEEE identifier.

Fine.   But no-one enforces that.  Nothing can rely upon it.   I can
trivially create addresses with u set to 1 which aren't created that
way.

In fact, I have just configured one ...

        inet6 3ffe:8001:2:181:200::2 prefixlen 64

You can probably ping6 that address.   (I hope I got the right magic bit,
I didn't actually calculate, and my mental arithmetic tends to be poor,
the 200 contains the bit I think is 'u').

Now the question here isn't whether or not I'm ignoring the standard,
clearly, as currently written, I am.   The question is how is someone
else supposed to tell, how, apart from the fact that the value happens
to be '2' in this case, that this doesn't contain a globally unique IID ?

  | I've tried to do so in another note.

Yes, I saw and replied.   I'm not convinced, as you will have seen.

  | Not so fast. To change the status quo, one needs more than just a
  | couple of people saying "yes" and the vast majority of the community
  | being silent.

Hmmm...

First, I agree that it is hard to tell what it means when most of a list
is remaining silent.   It can be anything between "that is obviously OK,
no-one is arguing against it, nor is anyone likely to, no need to send
a message about that" to "that is obviously bogus, no-one could possibly
agree with that, no need to send a message to point that out".

The usual way, if a proposal has support from more than just one person,
if to assume that it is supported, and say so, and then look for the
reaction.   Then if people disagree, there is an obvious incentive for
them to say so, and why - and then there's a better possibility for
a proper disciussion.   On the other hand, at that point, silence does
indicate consent - lacking objections, that's about the best mailing
list consensus you'll ever get (of course it rarely happens, someone
always objects, to everything...)

I might also suggest that you contract that position to what was done with
A6.  It was the status quo.   There there was a debate, with technical
arguments both sides (I disagree with one side, but still, they were
at least real arguments).   Quite a few people both ways.   And that's
enough for the status quo to change, apparently...

Here, there are still no technical arguments for why any of this is a
good idea - there's the "perhaps some future use" which really should
require at least some kind of suggestion of what it might be, and some
kind of evidence that has some hope of being effective, and the political
nonsense about /48's.

And there's the counter evidence that it isn't implemented, and 2026 which
says "not implemented == remove".

How much simpler can this possibly be?

kre

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 13 Aug 2002 13:08:17 -0400

>says "not implemented == remove".

What makes you say that this isn't implemented?

I am very familiar with two implementations that generate IIDs from EUI-64
identifiers and set the 'u' bit accordingly, and I am sure that most
other implementations do this as well.

That's the only think that the addressing architecture specifies that
you can/should do with the 'u' bit...

Margaret

---

From: Robert Elz <[email-masked]>
Date: Wed, 14 Aug 2002 14:16:42 +0700

Date:        Tue, 13 Aug 2002 13:08:17 -0400
    From:        Margaret Wasserman <[email-masked]>
    Message-ID:  <[email-masked]>

  | I am very familiar with two implementations that generate IIDs from EUI-64
  | identifiers and set the 'u' bit accordingly, and I am sure that most
  | other implementations do this as well.
  | 
  | That's the only think that the addressing architecture specifies that
  | you can/should do with the 'u' bit...

That's fine, and I'm not advocating removing that part of the draft (nor
were you when you posted your original message, I didn't think).

What I want to remove are the words that say that an address with the 'u'
bit set contains an IID that has global scope (which isn't actually defined
anyway, that is what does "has global scope" actually mean?)

That is, I have no doubt the implementations set the 'u' bit the way
you say they do, so do the ones I have seen.

But do they also clear the 'u' bit when the IID doesn't come from an EUI-64?

None I have seen do that.   That is, do as I did (and showed) in the message
I sent yesterday, try configuring

	prefix::0200:0000:0000:0001

(or anything you like in the bottom 48-56 bits) and see if the
implementations you are familiar with either reject that (give an error)
or silently clear the 'u' bit.

If they don't - they're not implementing 'u' the way the arch doc claims
it should be implemented.

kre

---

From: Shannon -jj Behrens <[email-masked]>
Date: Wed, 14 Aug 2002 19:10:42 -0700

<snip>
> there's actually some benefit that I just can't see.
<snip>

I, for one, am silently agreeing with you.  As best I can tell, here are the
arguments involved (I will present each argument followed by my opinion on the
argument):

1) The u bit only makes sense if we keep the 64-bit boundary, so we must keep
   the 64-bit boundary just in case we one day figure out how to use the 
   u bit.

   This argument should be removed because even Michael Py states that it is 
   a red herring.  I.e., even Michael Py states that the strength of his 
   argument for keeping the 64-bit boundary does not rest on the possible uses
   of the u bit.

3) EUI-64 is good.  It shouldn't be removed!

   No one is advocating this.  In fact, what we are advocating does not have
   any influence on how anyone else chooses to operate.  I am simply asking
   for the freedom to use the last 64 bits in whatever way I choose.

3) The draft should not be updated.  Instead, stability is crucial.

   The draft is already being updated.  Furthermore, removing the 64-bit
   boundary does not appear to have an affect on any existing implementations.

3) Current implementations do not enforce the 64-bit boundary, nor do they 
   enforce the uniqueness implied by the u bit.

   I am slightly unclear about these two points.  I have seen that 
   implementations do not inforce the uniqueness implied by the u bit; 
   however, it has already been decided to ignore the u bit in this argument.
   I am not sure if implementations forbit prefixes longer than 64-bits.
   Based on what I have read on this list, they don't.  If this is true, than
   it is fair to say implementation experience has proven that the 64-bit
   boundary is not necessary.  Implementation experience is a very valid 
   reason to update the draft.

4) Current practice does make use of prefixes longer than 64 bits.

   This increases the strength of the argument in number 3.  Current practice 
   should indeed have an influence on whether or not this draft should be 
   updated.  In other words, because using a /126 has been proven to be safe
   for point-to-point links, there is no reason to forbid it.

4) Allocation efficiency for point-to-point links.

   Some people feel that the the overhead of using a /64 for a point-to-point
   link is small, and quite justifiable if it simplifies things.  Others feel
   that space should not be wasted, and that any simplification achieved is 
   not justifiable, in this case.  I feel that the amount of time you spend
   arguing a point should be based on the relative importance of the point.
   Having said that, I'd like to say...nothing (i.e. the importance of this
   point does not justify further argument) :)

5) I want to have maximum freedom with my /64.

   This is the most important argument, in my mind.  I don't think any benefit
   gained from establishing a 64-bit boundary can possibly justify loosing 
   the freedom of not being confined to that boundary.  I think that this 
   point will become increasingly important in the long run.  Furthermore, I 
   think any arguments in favor of the 64-bit boundary will likely become less
   important in the long run.

6) Not establishing a 64-bit boundary will make the lives of ASIC designers
   difficult.

   I know nothing about designing ASIC's.  However, I presume that the header
   chaining used in IPv6 is an even more difficult challenge for ASIC
   designers.  Hence, I doubt this argument has real merit.

7) Using a 64-bit boundary may permit certain memory optimizations since 
   every prefix will be at most 64 bits long.

   This argument has been disproved in this thread twice.

In summary, I feel that experience has shown that the 64-bit boundary is 
unnecessarily confining and should be removed.

Best Regards,
-jj

-- 
o*s*o*pho*bi*a n. A common fear among embedded systems programmers.