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

From: Margaret Wasserman <[email-masked]>
Date: Mon, 05 Aug 2002 15:40:27 -0400

Well, first let me publicly apologize for bringing up these issues
with the Addressing Architecture document after it has officially been
through last call (multiple times).

Also, I'd like to state that I'm not speaking on behalf of the WG
co-chairs or anything.  So, you can just feel free to ignore my late, and
possibly misguided, thoughts on this subject...  My co-chairs definitely
don't agree with me, and I'm willing to admit that they know a lot more
about this subject than I do.

In re-reading the addressing architecture, I'm actually not sure whether
or not there is a problem here.  It does state what I mentioned earlier:

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

But, it also states:

"IPv6 unicast addresses are aggregatable with prefixes of arbitrary 
bit-length similar to IPv4 addresses under Classless Interdomain Routing."

Is this sufficient to allow autoconfig and privacy to require /64
addresses on end-node networks, and to allow operators to manually
configure longer prefixes for their point-to-point links?

I'm mainly concerned that the current wording will lead to one of two
things:

         - People building equipment that doesn't understand prefixes
                 longer than /64 -- if so, what happens when this
                 equipment is placed on a manually configured network
                 with a longer prefix?
         - Other IPv6 standards relying on a hard /64 boundary, and not
                 functioning properly on networks with longer prefixes.

Does anyone else think that these are real concerns?

Or, do you think that people who ignore the IPv6 architecture in configuring
their networks just get what they deserve?

Can anyone explain _why_ operators want to configure longer prefixes when
there are so very many /64 prefixes available?  Is this just because that's
how it's always been done?  Or are there actual technical reasons to prefer
a much smaller address space on a point-to-point link?

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: Thomas Narten <[email-masked]>
Date: Mon, 05 Aug 2002 16:06:45 -0400

Hi Margaret.

> through last call (multiple times).

Note: In the IETF, valid technical issues can be brought up until the
IESG has approved the document. There is no notion that once a LC has
happened, valid issues cannot be raised. That doesn't mean one should
wait until after LC to raise issues, of course. But the idea that one
should not raise issues because it's technically procedurally too
late, I find at odds with the IETF tradition of doing the technical
Right Thing. Of course, the later an issue is raised, the harder it
generally is to sway the WG.  So the arguments need to be strong.

> co-chairs or anything.

Good to be clear on this in general!

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

>                  equipment is placed on a manually configured network

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, (or that an implementation might hardwire things about
format prefix 001 being the only legal one), etc. But other folks were
still worried that people might still make poor implementation
choices, so words have been changed a number of times to make this
more clear just to be sure. The current document is a lot better in
this regard than its predecessor, IMO.

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.

>                  functioning properly on networks with longer prefixes.

AFAIK, no specs make this assumption. We consciously decided NOT to
change ND/addrconf, for example, to say prefixes needed to be
/64s. Other prefix lengths are still supported. 

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

Thomas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 6 Aug 2002 09:11:04 +0300 (EEST)

On Mon, 5 Aug 2002, Margaret Wasserman wrote:
[...]
> Does anyone else think that these are real concerns?

This would become one.

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.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Robert Elz <[email-masked]>
Date: Tue, 06 Aug 2002 17:27:24 +0700

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