Subject: RE: /127 for P-t-P Considered Harmful

From: Erik Nordmark <[email-masked]>
Date: Wed, 7 Nov 2001 21:57:20 +0100 (CET)

The subnet anycast address and the other ones reserved in 
RFC 2526 "Reserved IPv6 Subnet Anycast Addresses"
seems rather analogous to the subnet broadcast address in IPv4 -
basically reserving some bit patterns in the low order bits of the IP
address.

For IPv4 we have RFC 3021 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links"
which works for router-router links by boldly saying that such
links don't have a subnet broadcast address.

Why couldn't we define the /127 prefixes analogous to that - declaring
that such links don't have a subnet anycast address and no reserved ones
either.

Working the same as IPv4 practice can't be a disadvatage.

    Erik

--------------------------------------------------------------------
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: Charlie Perkins <[email-masked]>
Date: Wed, 07 Nov 2001 19:57:01 -0800

Hello Erik,

> that such links don't have a subnet anycast address and no reserved ones

Of course you can do that.  However, then there will be some applications
that try to access anycast addresses (perhaps on the same link) that will
instead bother some other computer that may even run the same application
as an anycast host might do.

> Working the same as IPv4 practice can't be a disadvatage.

I'm sure you meant that in the context of this very specific discussion,
not as a general design rule.

Otherwise we'll have to start building IPv6 NAT boxes right away.

Still no one has pointed out any downside on reserving the space by
restricting prefix lengths.  Robert Elz's point was the best/only one so
far, which is that fewer rules are better.  But the rest of your note,
which I didn't quote, amounts to some more rules.  And I don't see
why applications should have to know rules about subnet prefix
lengths in order to work better:

If ((prefix_length > 120)  &&
    (destination_address == anycast_foo)) {
                          printf ("Weird error message");
                          exit(99999999999999);
}

Plus, why shouldn't a host on a point-to-point link be able to run some
nifty applications that anycast is supposed to enable?  If you say that
there aren't any yet, then that's a strange reason given that IPv6 doesn't
exactly have killer apps yet.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 8 Nov 2001 18:51:58 +0100 (CET)

> as an anycast host might do.

For the currently defined use of anycast (the subnet anycast which isn't used
by anything and the home agent anycast) this is not a problem. Even if
a HA is attached to such a link you can avoid the problem by not configuring
the MNs to have that as their home link.

> Otherwise we'll have to start building IPv6 NAT boxes right away.

Stated with a bit more detail to clarify what I mean it does make sense
as a general design rule.

If there is IPv4 designs, protocols, and/or operational practises
IPv6 should follow those unless there is a good reason.
Thus IPv6 shouldn't choose to do things differently just because it can
be done differently but instead look very carefully at the
cost of being different than IPv4 (in terms of mindshare, training, etc)
and the benefits.

> restricting prefix lengths.

And I don't think anybody has pointed out the benefits and argued that
those benefits exceed the cost of training folks that e.g. a /31 in IPv4
corresponding not to a /127 but to something else.

>  Robert Elz's point was the best/only one so

How many "applications" do we expect to use subnet reserved anycast addresses?
(and what is your definition of "application"?)
Mobile IPv6 uses them but that is IP infrastructure and not an application
in my notion of the meaning of "application".

> exactly have killer apps yet.

We are not talking about arbitrary pt-pt links. We are talking about
pt-pt links between routers that have been explicitly configured to
save on address space. 
Thus if folks want to run those applications don't configure the pt-pt
link that way.

  Erik

---

From: Alain Durand <[email-masked]>
Date: Mon, 12 Nov 2001 16:52:41 -0800

=> From draft-ietf-ipngwg-addr-arch-v3-06.txt

2.5.1 Interface Identifiers

Interface identifiers in IPv6 unicast addresses are used to identify 
interfaces on a link.
[...]
For all unicast addresses, except those that start with binary value 000,
Interface IDs are required to be 64 bits long and to be constructed
in Modified EUI-64 format.

=> I read this as either P-t-P links do not share a common prefix
(i.e. both addresses can come from totally different address space)
or if they share a prefix, it MUST be a /64. Any other values
like /120, /124, /126, /127 are illegal [except in the 000/3 prefix]

	- Alain.