Subject: RE: [rfc2462bis issue 281] Requirement for 64bit I/F ID

From: "Barany, Pete" <[email-masked]>
Date: Tue, 25 May 2004 11:02:45 -0700

I also brought this issue up several months ago and received no
follow-up. I agree that it is shortsighted.

- Pete

See e-mail directly below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Barany, Pete
Sent: Saturday, December 20, 2003 9:01 AM
To: Brian Haberman; Stephen Sprunk
Cc: [email-masked]
Subject: RE: Question about Interface ID length

More generally, I still don't see why there is a restriction on the
prefix length for all IPv6 unicast addresses where the first 3 MSBs are
other than 000. I could understand the wording in RFC 3513 (and RFC
3513bis) if the restriction was intended for "unicast addresses that are
configured via stateless address autoconfiguration" (thus my initial
comment about the need to update RFC 2462bis). But some operators may
want to use DHCPv6 (stateful address autoconfiguration) where there is
no concept of prefixes per se (just 128 bit addresses). Therefore, as an
example, if an operator wanted to have a /65 subnet(or some other subnet
where the prefix is greater than /64) (and I am not saying that this is
a good idea), at least the RFCs wouldn't prohibit it in the
present/future. It seems like an unnecessary/unwise limitation IMHO.

Regards,

Pete

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Keith Moore
Sent: Tuesday, May 25, 2004 10:14 AM
To: Brian E Carpenter
Cc: [email-masked]; [email-masked]
Subject: Re: [rfc2462bis issue 281] Requirement for 64bit I/F ID

I am still of the belief that limiting the routing prefix to 64 bits is
a 
shortsighted design choice that will limit the lifetime and
applicability
of IPv6.  Anything we can do to discourage the notion that an interface
ID shall be 64 bits now and forever is, IMHO, a good idea.

Keith
 
> Architecturally, this appears to be the correct solution.
> 
> (I would expect a lot of protest at any proposal to *actually*
> deviate from 64 bits, but that is another discussion.)

-- 
--
Regime change 2004 - better late than never.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 May 2004 01:32:10 +0300 (EEST)

> follow-up. I agree that it is shortsighted.

For what it's worth, I think most ISPs use longer than 64 bit subnet
prefixes in numbering their loopback or point-to-point addresses, and
are quite happy about it.  

On the other hand, there are a number of features like SEND and 
RFC3041 which do use these features.  We don't want to get into the 
situation where people would start complaining that RFC3041/SEND would 
have to be forward-ported to arbitrary prefixlengths because folks 
later figured they'd prefer to use SEND/RFC3041 or something like that 
in the future.  In other words, I think using non-64 bit prefix 
lengths is just fine in the scenarios where you *know* that you won't 
be needing the possible fancy new features that could be provided only 
for 64 bit prefixes.

A comment below on your forwarded mail..

> no concept of prefixes per se (just 128 bit addresses).  [...]

Actually, /64 makes some sense for DHCPv6 address assignment as well, 
because you want to aggregate the routing table entries at the first 
hop ISPs, assuming that you have multiple users on a subnet.

Of course, the length would not need to be exactly /64, but why not to
make it consistent for DHCPv6 and non-DHCPv6 alike..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings