Subject: Last Call: IP Version 6 Addressing Architecture to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 12 Nov 1997 18:30:53 -0500

The IESG has received a request from the IPNG Working Group to consider
the following:

 o IP Version 6 Addressing Architecture
   <draft-ietf-ipngwg-addr-arch-v2-05.txt> for publication as a Proposed
   Standard.

   Note: This document is a replacement for RFC1884, which will be
	 reclassified as Historic.

 o  An IPv6 Aggregatable Global Unicast Address Format
    <draft-ietf-ipngwg-unicast-aggr-02.txt> for publication as a Proposed
    Standard.

    Note: This document is a replacement for RFC2073, which will be
	 reclassified as Historic.

 o IPv6 Testing Address Allocation
   <draft-ietf-ipngwg-testv2-addralloc-01.txt> as an Experimental protocol.

   Note: This document is a replacement for RFC1897, which will be
         reclassified as Historic.

 o IPv6 Multicast Address Assignments
   <draft-ietf-ipngwg-multicast-assgn-04.txt> as an Informational RFC.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by November 26, 1997.

Files can be obtained via 
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-05.txt
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-02.txt
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-testv2-addralloc-01.txt
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-04.txt

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 13 Nov 1997 17:58:01 -0600

To the IESG,

I think we, the IPNG working group, may have made a poor
choice in deciding to complement the universal/local bit
when forming an IPv6 address from an EUI-64 identifier.
(For details, see draft-ietf-ipngwg-addr-arch-v2-05.txt
or draft-ietf-ipngwg-trans-ethernet-04.txt.)  It's a poor
choice I could live with, but I'm hoping it can be
scrutinized first by individuals who weren't involved in
the choice.  As long as the point is examined, any
outcome will be acceptable.

The trade-off, as I see it, is this:

With the current documents, small integers may be freely
used as interface identifers, forming, for example, the
Subnet-Router anycast address which neatly ends with 64
zero bits.  But nodes auto-configuring their IPv6 unicast
addresses must flip a single bit in their built-in
address to form their Interface Identifier.

The Address Architecture and the IPv6-over-(various 802
media) devote several paragraphs to explaining the bit-
flipping, and the identities of nodes whose IPv6
addresses appear in neighbor tables or packet traces are
slightly obscured by the alteration of the bit.

If the spec were written the other way, so that an EUI-64
is used directly as an Interface Identifier, the language
in the documents would be simpler, MAC addresses would be
somewhat more recognizable in packet traces or tables.

On the down side, those small-integer identifiers would
have to look like this
				3ffe:7c0:40:9:200::0
instead of the current
				3ffe:7c0:40:9::0

We might arguably appear a little more IEEE-friendly by
not fiddling with the bit, but I can't really make a case
on that argument.  The simplification of the specs is my
main point.
				Matt Crawford

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Nov 1997 13:12:24 +0000 (GMT)

I concur with Matt, and in addition I believe that this bit
inversion will cause endless (literally) confusion to at least
a generation of network operators and maintenance techs.

  Brian Carpenter

>- Matt Crawford said:
> --------------------------------------------------------------------
> 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: Dimitry Haskin <[email-masked]>
Date: Fri, 14 Nov 1997 12:09:52 -0500

I disagree with Matt on this issue.

To be frank, I don't think that it makes much technical difference one way
or other.  Nevertheless, at the point where there are a score of
implementations and at least one released product that incorporate the
previously agreed interface identifier format, changing it for the sake of
removing a couple paragraphs from the specs is not a justifiable tradeoff
and only add to confusion. In addition, it will increase the probability
that an incorrect interface identifier will be generated with manual
configuration.

As to the concern that MAC addresses are not readily recognizable in IPv6
addresses, I don't think that it is a detriment but rather a benefit.  Let
me remind that EUI-64 identifier has been chosen only as a convenient base
for deriving globally unique IPv6 interface identifiers. No other
relationships shell be implied from that. There has been past attempt to
utilize the interface identifier properties to bypass the ND's address
resolution mechanism. If flipping one bit can help to obscure the MAC
origin of interface identifiers, it's only for better.

Dimitry

---

From: Robert Elz <[email-masked]>
Date: Sat, 15 Nov 1997 13:26:28 +1100

Date:        Fri, 14 Nov 1997 12:09:52 -0500
    From:        Dimitry Haskin <[email-masked]>
    Message-ID:  <3.0.1.32.19971114120952.0073be28@pobox>

  | I disagree with Matt on this issue.

I agree with Dimitry - and if we were to open this issue again, which I
certainly hope that we don't, I'd suggest mangling the EUI-64 much more than
just by inverting a bit.  That is, instead of xoring the EUI64 with
	0200000000000000 (hex)
I'd suggest xoring it with something like
	32e71064cf254819

such that it is absolutely unrecognisable as a related MAC type address
(while still being exactly as unique).   (Assigned addresses would still
be used as assigned - and would keep that local/global bit clear).

We need to make it 100% clear that IPv6 addresses do not contain EUI-64's,
rather they are sometimes derived from an EUI-64.

kre

---

From: Grenville Armitage <[email-masked]>
Date: Sat, 15 Nov 1997 13:36:29 -0500

Matt Crawford wrote:
	[..]
> The simplification of the specs is my
> main point.
>                                 Matt Crawford

I concur with Matt's concern. The IPv6 over NBMA spec required
somewhat stilted text (although that might just be my writing
style ;-) to explain why we were building on an EUI-64 number
space but flipping the semantics of one particular bit.

If we were simply lifting a semantic-free
64 bit field from somewhere then assigning our desired
semantics to one bit it would be easy. But we're
flipping 'existing' semantics for reasons that are not
trivially apparent.

Perhaps Dimitri is right, its too late to change, but I'd
certainly feel more comfortable in 5 years if I didn't
have to repeatedly explain to implementors, students, professors,
etc.... the non-obvious reasons for the flip.

cheers,
gja
________________________________________________________________________
Grenville Armitage                          High Speed Networks Research
http://nj5.injersey.com/~gja              Bell Labs, Lucent Technologies

---

From: Peter Curran <[email-masked]>
Date: Sun, 16 Nov 1997 12:32:06 +0000 (GMT)

Matt

> outcome will be acceptable.

I am an individual, I wasn't involved in the choice (I did not voice
and opinion at the time) and I have scrutinised the result of the
decision.

I may have missed something important here (probably :-), but I think
that you have misconstrued an important point.  The fact the 64bit i/f-ID
is generated from a MAC address is irrelevant.  You can use whatever
numbers you want, as long as they are unique on the link. Just because we
have to jump through some hoops to **automatically** turn a 48-bit
MAC address into a unique 64-bit value doesn't mean that the MAC->EUI-64
rules have to be used anywhere else.

I agree that the logic behind flipping the G/L bit is tortuous
- hell, I think it is a pretty dumb idea - but it is a done deal.

> address to form their Interface Identifier. [.....
> 
> ....]  If the spec were written the other way, so that an EUI-64

I disagree.  Changing the meaning of the bit has no impact on this
example.  The autoconfigured address is derived from a MAC address,
but the other interface is not and can use what it likes - so long as it
is unique within its scope.

Cheers

Peter Curran
TICL

---

From: [email-masked]
Date: Mon, 17 Nov 1997 09:54:47 -0500

I just want to say we implemented this and its up and running.  Also the
MAC addresses are distinguishable.  I am with Dimitry on this one.  

/jim

---

From: Gregory Taylor <[email-masked]>
Date: Mon, 17 Nov 1997 23:13:29 -0800 (PST)

Patches for the ip_fragment bug (tear.c) can be located at
www.rootshell.com, thank route for the patch to this error... new versions
of linux and BSD will feature the patch already in the newest kernels.

Thank You,

Gregory Taylor

Owner
Resourceful Network Solutions, Inc.
(253) 475-1227
[email-masked]

---

From: Daniel Karrenberg <[email-masked]>
Date: Wed, 26 Nov 1997 18:05:00 +0100

Authors

Robert Blokzijl 
RIPE Chair

Daniel Karrenberg
RIPE NCC General Manager

Background

RIPE is an organisation founded in 1989 wich aims to ensure the
technical and administrative coordination necessary for the operation of
the Internet in Europe [ripe-01]. 

The RIPE NCC performs activities for the benefit of the Internet service
providers (ISPs) in Europe and the surrounding areas; primarily
activities that the ISPs need to organise as a group, although they may
be competing with each other in other areas.  In particular the RIPE
NCC, as Regional Internet Registry, allocates and assigns IPv4 address
space in Europe and surrounding areas [ripe-162].  The RIPE NCC started
operations in 1992.  It currently allocates address space to more than
800 local Internet Registries almost all of which are operated by ISPs. 
The number of local IRs is expected to reach 1250 in 1998.  There are
currently no indications that the number of local IRs will stop growing.

The authors have contributed significantly to the development of the
distributed Internet registry system which is used for the allocation
and assignment of provider based IPv4 address space today.  As such they
have ample experience with the development of address space allocation
and assignment policies.  One important element of current policies is
that the size of address space allocations is determined by previous
justified use of address space.  A prerequisite for this policy is that
the size of allocations can start small and increase or decrease 
according to previous justified usage [ripe-159].

Argument

We believe <draft-ietf-ipngwg-unicast-aggr-02.txt> is critically flawed
because it standardises address aggregation boundaries without any
explicit technical justification.  In particular the length of the TLA
and NLA fields are proposed to be standardised as fixed at prarticular
values with no technical justification for either the fact that these
lengths need to be fixed nor for the particular values chosen.  The lack
of technical justification is significant because the standardisation of
TLA and NLA lengths directly influences many elements of Internet
operations including address space allocation policies.  In particular
the TLA being fixed at 13bit length makes only 8K TLAs available per FP.
Consequently Internet Registries will not be able to use proven
allocation policies but rather engage in regulatory practises.  The
rules proposed in <draft-ietf-ipngwg-tla-assignment-01.txt> are clear
evidence of this.  Broad acceptance of such rules and their implementation 
is extremely unlikely unless there is convincing technical reasoning 
behind the constraints that necessitate the rules. 

Because of this critical flaw we request that the IESG not advance
<draft-ietf-ipngwg-unicast-aggr-02.txt> and
<draft-ietf-ipngwg-addr-arch-v2-05.txt> to proposed standard yet.  We
suggest that the IESG refer these documents back to the authors and the
WG with the request to provide technical justification for the placement
of aggregation boundaries and to consider making these boundaries
variable where technically feasible. 

References

The referenced RIPE documents can be accessed at

http://www.ripe.net/docs/ripe-xxx.html		HTML
ftp://ftp.ripe.net/ripe/docs/ripe-xxx.txt	ASCII
ftp://ftp.ripe.net/ripe/docs/ripe-xxx.ps	PostScript

---

From: [email-masked]
Date: Mon, 01 Dec 1997 12:08:32 -0500

Daniel,

Have you or someone from RIPE participated on the IPng mailing list?

Have you or someone from RIPE participated in the IPng WG meetings at
the last three IETF meetings?

The reason I ask is because we have done technical analysis on this and
have had much discussion.  

I think discussing the reason for going with a 13bit TLA needs to be
brought out more and doing and checking that is prudent.  But the
architecture and reasoning has had many technical discussions.  I would
like to understand as a WG member if you or RIPE did not agree with the
results (which I would think we would have heard before now) or if you
or RIPE have not been part of these open public discussions.  It could
be we need to point to the mail archives and the GSE reasoning paper done 
by Thomas Narten, Lixia Zhang, et al from whence this essential proposal
came from based on a WG meeting in Mountain View about a year ago?

I am trying to understand if this is an educational effort on our part
as a WG group?

thanks
/jim

---

From: Daniel Karrenberg <[email-masked]>
Date: Mon, 01 Dec 1997 20:19:01 +0100

Quick answer:

  > [email-masked] writes:
  > Daniel,
  > 

Yes we have.  I personally have not been in Memphis, hoever none of us was
able to be at the interim meeting.  To my knowledge the draft under
discussion was written less than two IETFs ago.  I personally was not
able to be at all IPnG meetings at the last few IETFs because of
conflicts with other things.  I have however voiced my concerns about
this particular issue to Miek O'Dell while the discussion was going on.

But all that is besides the point really.

  > have had much discussion.  

I have seen some of this discussion.  I am afraid I have seen no
documented discussion revealing the reasoning behind fixing the TLA
length and fixing it at 13 bits.  Frankly I have been surprised by the
sudden speed of the provider based addressing standardisation. 

What I have voiced are concerns based on our experience with setting up
and operating address space registries as well as providing coordination
services to ISPs.  My main point is that fixing the TLA length and
fixing it at 13 bits has such far-reaching consequences that it needs to
be supported by a solid technical argument which I cannot find in the
drafts nor in any other source available to me.  I think the
draft should at least point to a solid reference supporting this. 
I expect a lot of entropy down the road if this is not supported well.

  > I am trying to understand if this is an educational effort on our part

It is both educational and principal.  Major design decisions should be
somewhat transparent to a wider audience.  Standardising TLA length in
fact puts significant constraints on operations, business models and
address space allocation policies just to name a few issues.  This needs
to be justified somewhat more than just saying "it is standardised like
this".  The reasons have to be accessible more widely than just the IPnG
WG.  Note that I am not at issue with the underlying architecture.  It
is about fixing the boundary and fixing it at a particular value.  If
there is a solid technical reason for it, then document it.  Documenting
it will make the standard a stronger document and will prevent a lot of
discussion about the repercussions.  If there is no solid technical
reason to do so then then do not fix these values.  If a (proposed)
standard does not document this reasoning or at least points to it, it
is seriously flawed. This is not a definition of a type field in some
application protocol header. It is much more critical.

Does that answer your question?

Daniel

---

From: [email-masked]
Date: Mon, 01 Dec 1997 15:02:06 -0500

Daniel,

Good answer.  I agree.
Be helpful in the future if you would state your concerns to the WG
directly as we may have been able to have done this before going to the
IESG.  I recall no mail from Mike O'dell to this list on the TLA issue.
But we need to address your concern for sure.  I have had many ask
about the 13 bit issue and figured that would pop up.

thanks
/jim