Subject: RE: IPv6 Addr/Prefix clarification

From: "Michel Py" <[email-masked]>
Date: Wed, 23 Jan 2002 08:13:44 -0800

>> Irina Dayal wrote:
> 1) Is it safe to assume that all IPv6 prefixes will be between
>> 16 and 64 bits long?

> Keith Moore wrote:
> no.  because nothing requires a site to use the lower 64 bits
> as an interface ID - a site is free to subnet that space if
> it wishes.

I have to disagree with Keith here. If a site wants to subnet,
they get a /48 and use the 16 SLA bits to subnet, that is what
they have been designed for.

Michel.

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Wed, 23 Jan 2002 12:33:03 -0500

> they have been designed for.

depends on what you mean by 'site', I suppose.  Even if RFC 3177 is 
followed, I would not want the network to presume that a /64 net
(such as might be assigned to a mobile network) should never be
subnetted.  there are good reasons to occasionally subnet a mobile
network.  and if we are not careful about how we allocate the 
top 64 bits we might need to allow subnetting of the lower 64 bits.

In general, code and hardware should not presume much about the 
structure of addresses.

Keith

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Jan 2002 09:39:40 -0800

Michel,

Keith is technically correct, a site may choose to subnet the low 64
bits. It might be unwise to do so, because they would be giving up the
autoconfiguration & privacy capabilities, but that is their choice. They
may also find acquiring routing hardware that works beyond the 64 bit
prefix to be a challenge ...

Tony

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Michel Py
> Sent: Wednesday, January 23, 2002 8:14 AM
> To: Keith Moore; Irina Dayal
> Cc: [email-masked]
> Subject: RE: IPv6 Addr/Prefix clarification
>
>
> >> Irina Dayal wrote:

---

From: JJ Behrens <[email-masked]>
Date: Wed, 23 Jan 2002 11:18:18 -0800 (PST)

> From: Tony Hain <[email-masked]>

Please forgive me for being a newbie, but it seems wise to allow
subnetting of the lower 64 bits. Afterall, it would be terrible if my
dialup ISP assigned a /64 to me, and I had to rely on some IPv6 mythical
NAT to do subnetting!

A /64 is really quite a lot of address space to subnet; without the
ability to subnet, a /64 seems wasteful. In response to the address
autoconfiguration using MAC addresses argument, address autoconfiguration
can be done using something other than the MAC address in those
circumstances. The fact that neighbor solicitations are used to verify the
uniqueness of tentative addresses is proof enough that MAC addresses were
never meant to be the end all and be all of address autoconfiguration.

 -jj

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 23 Jan 2002 14:22:18 -0800

JJ,

This argument comes up frequently from people that are looking at IPv6
for the first time. First, ignore the number of bits for the moment and
look at the differences between the versions. In IPv4, your ISP
allocates a host address, while in IPv6 the allocation is a subnet at a
minimum, and should be a block of subnets in the general case. Since the
dial allocation is a subnet, there is no requirement to use NAT, when a
simple layer-2 bridge will do the job. There is also a concept
frequently referred to as multi-link subnets, which differs from a
layer-2 bridge only in the fact that forwards based on layer-3 packets
rather than layer-2 frames, but considers all interfaces to be part of
the same logical layer-3 subnet. Using either of these technologies you
will be able to have a substantial number of nodes connected through a
dial link.

Now as for the number of bits, there are several capabilities that have
been built based on the availability of 64 bits for the interface id.
Auto-configuration based on EUI64/48 mac is just the first. Privacy (RFC
3041) requires a large number of bits to avoid collisions; automated
allocation of multicast addresses
(draft-ietf-ipngwg-uni-based-mcast-03.txt) needs space to divide the
group space by prefix; and ISATAP (draft-ietf-ngtrans-isatap-02.txt)
uses the space to encode a tunnel endpoint for non-multicast IPv4
infrastructures. Others may show up to solve specific problems, so
trying to be too conservative with bits is actually wasteful in terms of
time and flexibility of deployments.

I hope this helps,
Tony

> From: JJ Behrens [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2002 11:18 AM
> To: Tony Hain
> Cc: Michel Py; Keith Moore; Irina Dayal; [email-masked]