Subject: Fwd: RE: (ngtrans) 6to4 gateway / 6to4 relay routerIPv4-compatibleIPv6 address interoperability concern ...

From: Alain Durand <[email-masked]>
Date: Wed, 13 Jun 2001 19:59:29 -0700

Repost in plain ASCII. Sorry for the wrong format....

         - Alain.

>At 08:41 AM 6/13/2001 -0700, Christian Huitema wrote:
>>Third, the choice of the "0000" subnet-id is poor. According to section
>>2.6.1 of the IP Version 6 Addressing Architecture
>>(draft-ietf-ipngwg-addr-arch-v3-05.txt), "2002:ip:v4::/48" is the
>>"required Anycast Address" for the entire site connected through the
>>6to4 router(s). This prefix will be matched by any IPv6 router in any
>>subnet in the site -- not just the 6to4 gateway.
>
>2.6.1 Required Anycast Address
>
>    The Subnet-Router anycast address is predefined.  Its format is as
>    follows:
>
>
>    |                         n bits                 |   128-n bits   |
>    +------------------------------------------------+----------------+
>    |                   subnet prefix                | 00000000000000 |
>    +------------------------------------------------+----------------+
>
>
>    The "subnet prefix" in an anycast address is the prefix which
>    identifies a specific link.  This anycast address is syntactically
>    the same as a unicast address for an interface on the link with the
>    interface identifier set to zero.
>
>    Packets sent to the Subnet-Router anycast address will be delivered
>    to one router on the subnet.  All routers are required to support the
>    Subnet-Router anycast addresses for the subnets which they have
>    interfaces.
>
>    The subnet-router anycast address is intended to be used for
>    applications where a node needs to communicate with one of a set of
>    routers on a remote subnet.
>
>=> When I read this, my understanding was that this is applicable to 
>subnets only.
>My understanding of subnets is that they are /64 prefixes and not site, 
>/48....
>
>Of course, the bit patterns seems to imply otherwise...
>
>Bob or Steve, could you please clarify my confusion?
>
>         - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2001 16:43:53 -0500

In any case, I don't see why defining a unicast address competes with
defining an anycast address. When 6to4 routers talk to each other
(e.g. for BGP4+ which is one of the standard scenarios) they need
to know each others' unicast address, and Alain's draft suggests
a default choice. It isn't absolutely required that we define this;
in fact I would make it Informational, since it is just a hint.

   Brian

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Jun 2001 09:49:59 -0700

>>   The Subnet-Router anycast address is predefined.  Its format is as

Alain,

You are correct.  The address architecture draft defines only the subnet
anycast address.  However, I think it is desirable to be able to
generalize this to say that any prefix (i.e., set of leading subfields
of an address), followed by all-zeros, can serve as an anycast address
for the set of routers that bound the topological region identified
by that prefix.  In fact, the draft guidelines for IPv6 address
allocation that was developed by the registries last year required
that sites treat the site prefix as an anycast address for the site
boundary routers; this was so the allocation authorities (RIRs, LIRS,
or ISPs) could ping the prefix to see if it was in use (you could
imagine that long-term failure to answer such pings might be grounds
for reclaiming / garbage-collecting a site prefix).

>>Of course, the bit patterns seems to imply otherwise...

It is not meant to imply otherwise.  Are you drawing your conclusion
from the fact that the low-order field is labelled as "128-n bits"
rather than "64 bits"?  If so, you are making the common mistake
of assuming that all IPv6 unicast addresses have a 64-bit interface
ID field.  IPv6 unicast addresses that start with binary 000 can
have interface ID fields of width other than 64, e.g., embedded
NSAP-compatible or IPv4-compatible addresses.

Steve

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 13:22:10 -0400

> (you could

that might be fine if we accept that prefixes assigned by the registries
are only for use by sites connected to the public internet, and we provide
another means for non-public sites to get globally-unique prefixes (soon!)

but I don't think it's a good idea to insist that everyone who has an 
IPv6 prefix also has to be pingable from the public Internet.

indeed, it seems like IPv6 would be an attractive alternative to multiple 
layers of NATs (and all of the associated interoperability problems and
administrative hair) currently associated with inter-enterprise IPv4 VPNs.

Keith

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Jun 2001 10:58:08 -0700

>another means for non-public sites to get globally-unique prefixes (soon!)

One could imagine the registries also taking on the job of assigning
non-public site prefixes, and if so, they would presuambly exempt such
prefixes from the pingability requirement.

>administrative hair) currently associated with inter-enterprise IPv4 VPNs.

This is getting way off topic, but I don't understand the necessity of
inter-enterprise VPNs, at least in v6.  Companies don't typically build
virtual private phone networks for telephone communication with other
companies, why do they need to build virtual private internets for IP
communication?  The usual reasons claimed for using VPNs are to achieve
some QoS properties and/or some privacy-from-snooping guarantees, but
you don't need a VPN abstraction (let alone another layer of
encapsulation) for those -- just apply the applicable QoS mechanisms
directly to those packets whose addresses identify them as belonging to
the customer who has bought the special service (rather than using the
addresses to decide which packets to encapsulate, and then doing the QoS
on the encapsulating header), and use IPsec to provide the privacy
property (which may or may not entail its own extra layer of
encapsulation, depending on whether or not it's end-to-end).

Do you think there will be many enterprises that will choose to have
*no* connection to the public Internet and, therefore, no need or desire
for any public addresses?

Steve

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 14:13:13 -0400

> prefixes from the pingability requirement.

that would be fine.  presumably they would also exempt such prefixes
from the requirements designed to ensure aggregability of routes in
the public Internet.
 
> communication?  

I don't think it's a valid analogy.  

First of all, companies do build private phone networks to connect different
parts of the company with different phone number prefixes.

Second, telephones are used by people, and few companies think they should 
try to control who their employees can speak to outside the company.   
By contrast, it's quite common to want to limit public access to computers 
while still allowing those computers to communicate with computers
in other organizations.

> The usual reasons claimed for using VPNs are to achieve
> some QoS properties and/or some privacy-from-snooping guarantees, 

also limiting vulnerability to attack.

> for any public addresses?

I think there will be many enterprises that prefer for their private
traffic and public traffic to be on completely different networks, so they
are entirely isolated from one another - but who still want to be able to
connect portions of those private networks to portions of other private networks.

I also think there will be some enterprises that would be willing to use IPv6
internally (or on a bilateral basis between enterprises) long before they 
would be willing to have public IPv6 access.

we need to get folks away from the notion that private networks imply non-global 
address space.

Keith

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Jun 2001 14:18:02 -0700

>parts of the company with different phone number prefixes.

Understood.  I specifically referred to intER-enterprise.

I have often wondered why intRA-enterprise private phone networks typically
use different phone prefixes, rather than just using their public
phone prefixes but routing them internally -- is it due to limitations of
PBXs, the desire to support shorter dialing sequences for inter-company
calls, or something else?  (Some of those potential reasons would not
necessarily apply to an IP network.)  There has certainly been a non-
trivial cost to using a separate phone numbering space, in terms of
employee training, publishing and distributing company phone
directories, etc.

>while still allowing those computers to communicate with computers

That can all be accomplished with regular filtering firewalls -- you don't
need separate address spaces for that (despite the claims of those who
promote NATs as security solutions), nor do you need to build virtual
networks.

>also limiting vulnerability to attack.

Again, I don't see how imposing a VPN abstraction provides defenses not
otherwise available.

>connect portions of those private networks to portions of other private networks.

Are you talking about different physical networks or different virtual
networks?

>would be willing to have public IPv6 access.

Yeah, that sounds sorta reasonable.

>we need to get folks away from the notion that private networks imply non-global  address space.

I certainly agree with that.

We did (on the ipngwg list) discuss some of the issues regarding
non-globally-routed private /48s last time we debated the "what's a
site" topic.  I do see some advantages to having such private space
(despite my comments above and preceding, which are more questioning
the value of the inter-enterprise VPNs than non-routable address blocks).
A couple of the potential concerns are:

    - does this create the need for more address allocation bureaucracy,
      with all of its non-technical, ICANN-ish minefields?

    - will such unaggregated prefixes end up being injected into the
      global routing tables anyway (due to customers prevailing on a
      willing ISP to carry and advertise them)?

A possible alternative, previously identified by Paul Francis and maybe
others, that would help to sidestep those particular concerns would be
an address format like the following:

  +----------+--------------+--------+-----------------------+
  | shortish |    randomly  | subnet |  interface            |
  | format   |     chosen   | number |  ID                   |
  | prefix   |     number   |        |                       |
  +----------+--------------+--------+-----------------------+

That is, designate a part of the address space for non-aggregatable,
probabilistically-global addresses.  There would be a distinct format
prefix (so public backbone routers could easily recognize and suppress
routing info about such address blocks).  Any enterprise or collection
of enterprises could make up their own address blocks using a random
number generator.  If the randomly-chosen field is large enough, and
the generation sufficiently random, the probability of colliding with
other such prefixes used by the set of interconnecting enterprises
could be made small enough, even though true global uniqueness would
not be assured.

Would that satisfy the purposes of concern to you, or do you think that
true global uniqueness is essential for such address blocks?

Steve

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 17:46:48 -0400

> Understood.  I specifically referred to intER-enterprise.

well, these days mergers are so common that what are separate companies
today can easily be the same company tomorrow. 
 
> promote NATs as security solutions), nor do you need to build virtual

yes, but it's much easier (though less flexible) to configure the firewalls if 
the prohibited hosts are in a very different part of address space.

(true, you can get much more flexibility with a directory-based access control 
approach - you can set the granularity of access control at a single address.
but not everyone is willing to do this)

> Are you talking about different physical networks or different virtual

I'm talking about imposing filters on relatively large blocks of IPv6 space,
rather than on individual hosts.    The portions that are blocked might
or might not correspond to actual pieces of physical network topology.

which is not to say that I think this is a good architecture in the long
run, but that I see that some sites are going to want such things. 

more generally, I can see that some sites are going to want to do IPv6 to
talk to other sites - specifically because of the problems with IPv4 NATs -
and we shouldn't expect them to get an external IPv6 connection (or an address
block from one of the registries) just in order to do that.

>       willing ISP to carry and advertise them)?

I understand and share those concerns.  My guess is that if we start out 
with filters on that FP, that all major ISPs implement, they'll probably stick. 

Naturally, I'd like to avoid that bureaucracy if possible.  There's no
point to this exercise if it's as difficult to get a non-routable prefix 
as it is to get a routable one.

> an address format like the following:

It might be good enough.  Part of the trick is ensuring that the numbers
are really random.  Also, you need that field to be wide enough to make 
birthday collisions unlikely in practice.  Having a separate FP makes sense.

Another idea would be to delegate some prefixes to hardware vendors,
and let them dole out prefixes to their customers.  Maybe each router
could ship with a prefix already assigned, in case the customer
didn't have one already?

Keith

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Jun 2001 14:58:39 -0700

>could ship with a prefix already assigned, in case the customer

How about using the (48 minus the width of the FP) low-order bits of any
Ethernet address to fabricate an IPv6 /48 prefix?

Steve

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jun 2001 18:01:39 -0400

> Ethernet address to fabricate an IPv6 /48 prefix?

it might work.   it does have a certain elegance...

Keith

---

From: Alain Durand <[email-masked]>
Date: Fri, 15 Jun 2001 15:14:27 -0700

>for reclaiming / garbage-collecting a site prefix).

I understand I would make sense to extend this notion to sites.
However, I'm not sure it's safe to extend it to any prefix with plen < 48

>NSAP-compatible or IPv4-compatible addresses.

If that mistake is so common (I think it's also the second time
I'm making it, shame on me), maybe it will be worth putting
a note in the draft about it.

         - Alain.

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 15 Jun 2001 17:17:41 -0500

> it might work.   it does have a certain elegance...

Ugh.  If you did it, it would have to be the high-order bit, not
low-order, to avoid two vendors from generating some same prefixes.

And you want to throw out the two lowest bits of the first byte,
since they're not assignable.  That means that out of one OUI (a
"vendor code"), you can make 2^(26-len(FP)) prefixes, assuming
len(FP) >= 2.

But your motto for this has to be: "Delays, delays.  Now I shall have
to create more Martians!"

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Jun 2001 15:19:02 -0700

>However, I'm not sure it's safe to extend it to any prefix with plen < 48

When I have given tutorials on IPv6, I have often given the example
of an anycast address assigned to an ISP's routers, which can be
source-routed through (using the Routing header) on the way to a
final destination, as a way of doing "provider selection".  A prefix
assigned to an ISP would seem to be a natural thing to use as that
anycast address (assuming there's any merit in the general idea).

>a note in the draft about it.

OK, will do.

Steve

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Jun 2001 15:32:43 -0700

>low-order, to avoid two vendors from generating some same prefixes.

My goal was just probable uniqueness, not absolute uniqueness,
and I assumed the lowest-order bits were less likely to collide
with anyone else using the same trick than the highest-order bits.

[This reminds me: at Stanford in the mid 80's, we used some Ethernet
packet sniffing software that used the lowest-order byte of the Ethernet
address to identify the source(es) and/or destination(es) of interest,
and I don't recall ever finding two machines on the same Ethernet with
the same low-order byte value in their addresses.  (The software was
originally developed for the 3 Mbit Ethernet, whose address were
only 8 bits wide.)  Mind you, this was was in an environment that
preferred routers over bridges, so we didn't have extended Ethernets
with hundreds or thousands of nodes on them...]

Steve

---

From: Steve Deering <[email-masked]>
Date: Fri, 15 Jun 2001 15:40:56 -0700

At 3:32 PM -0700 6/15/01, Steve Deering wrote:
>...Mind you, this was was in an environment that
>preferred routers over bridges,...

I should have said "preferred gateways over bridges", since that's what
we called IP forwarding boxes in those good ol' days.

Sorry for the clutter -- pre-weekend brain drift....

Steve