Re: [GLOBAL-V6] Re:I-DACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
Brian E Carpenter <[email protected]> Fri, 22 Jul 2005 23:09:34 +0200
| Newsgroups | gmane.ietf.ipv6,gmane.org.apnic.global-v6 |
|---|---|
| Organization | IBM |
| Message-ID | <[email protected]> |
Manfredi, Albert E wrote:
> 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?
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------