Subject: RE: [GLOBAL-V6] Re:I-DACTION:draft-narten-ipv6-3177bis-48boundary-00.txt

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 20 Jul 2005 11:34:29 -0400

Not necessarily lots of funky services.

Here's the sequence that leads to this interface ID length question.

1. RFC 2373, the precursor of RFC 3513, introduces 64-bit IIDs. Okay,
seems logical. (Also reminiscent of NSAPA structure from back in ION wg
days.)

2. RFC 3513 strengthens that, suggesting that the IANA assign only
globally unique addresses starting in binary 001, which means by
extension that these will only have 64-bit IIDs. Okay, fair enough.

3. RFC 3177 suggests that every site be assigned a /48 prefix at least.

4. I-D 3177-bis introduces the idea that wanton waste is perhaps not a
good idea, and /56 prefixes would be a better idea than default /48
prefixes.

5. RFC 3041 says maybe those globally unique IIDs create a problem
anyway.

I come to some conclusions from this.

First, if 64-bit IIDs create security problems, then one possible remedy
is not to insist that all IANA assignments must use 64-bit IIDs.

Second, that if all IANA assignments do not have to consist of 64-bit
IIDs, the concerns of I-D 3177-bis are also alleviated.

Third, that the underlying model on which RFCs 3513 and 3177 are based
seems to be heavily biased to assignment of IP addresses from ISPs to
businesses and residences, client-server architectures, and address
autoconfiguration. But perhaps that's not going to be where the future
leads, for the vast majority of IPv6 devices and applications. Perhaps
we're looking at bewildering arrays of devices (sensors and actuators)
embedded in all manner of sites, including mobile platforms, roadways,
in individual home systems, where globally unique IIDs are not
appropriate and where very large numbers of relatively small IP subnets
are instead the norm.

So yes, this is a different discussion perhaps, but not unrelated. It
says, why are we following just this one path?

Bert

> -----Original Message-----
> From: Roger Jorgensen [mailto:[email-masked]] 
> Sent: Wednesday, July 20, 2005 5:27 AM
> To: JFC (Jefsey) Morfin
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [GLOBAL-V6] 
> Re:I-DACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
> 
> On Wed, 20 Jul 2005, JFC (Jefsey) Morfin wrote:
> > 
> > Up to now, what has been investigated is what IPv6 can bring to the 
> > network. I think another interesting approach is to start 
> from a universal 
> > numbering space and investigate what IPv6 could bring to it 
> (with the 
> > current technology or not) and to all its constituents. May 
> be the way to 
> > understand how to deploy IPv6 faster instead of selling it slowly?
> 
> This is a completly different discussion and IPv6 is just one of many
> tools available. Problem is, are no use in trying to create 
> lots of funky
> services if the communication wont work...  and no one 
> (almost) want to 
> use time and money on getting the communication to work 
> without a service 
> using it. 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jul 2005 23:09:34 +0200

> says, why are we following just this one path?

Because /64 isn't some theoretical construct that's easy to change.

It's built into innumerable specifications. It's shipped product.

And it isn't a significant problem, as far as I can see from
draft-narten-iana-rir-ipv6-considerations-00.txt

/48 *is* a problem, and seems quite easy to fix.

    Brian