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 PROTECTED]
Subject: Re: Thoughts on draft-savola-ipv6-127-prefixlen-04.txt
Date: Mon, 05 Aug 2002 16:06:45 -0400
From: Thomas Narten <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| 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 PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
