Subject: RE: IPv6 site-locals... end of story...

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 25 Mar 2003 10:56:54 -0500

> From: Curtis Villamizar [mailto:[email-masked]]

> NATs very much get in the way of peer-to-peer in case you weren't
> aware of that.  Try running any kind of server behind a NAT and
> accessing it from outside the NAT.  If two factory widgets are behind
> the same NAT they need unique addresses and you're back to DHCP or
> configured addresses.

If the entire peer-peer network is behind the NAT, the NAT won't bother it in the slightest. That was the scenario I was describing. Multiple such systems, installed in many different sites, all of them internally identical.

If there is a server outside the NAT, once again, the peer-peer network can remain identical in all instances and the NAT will take care of making the server appear identical to all hosts inside the NAT.

Comms outside the NAT may be expected to be infrequent, e.g. primarily for occasional remote system monitoring or remote troubleshooting. And these sessions may always be initiated outside the NAT, leaving the peer-peer network unchangerd in every case. 

My problem with all the arguments against a private address space in IPv6, and all the arguments in RFC 1627 too for that matter, is that these arguments assume the only motivation is to economize on address space. And yet, plenty of people have indicated otherwise.

Yes, it is always possible to create private networks with real but illegal global addresses. That's a nuisance and prone to creating problems. And I don't think that IPv6, by design, should make it mandatory for every private network to obtain globally unique addresses from the IANA. That's sort of obnoxious.

Bert
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Mar 2003 08:58:34 -0800

Manfredi, Albert E wrote:

> And I don't think that IPv6, by design, should make it mandatory
> for every private network to obtain globally unique addresses from
> the IANA. That's sort of obnoxious.

I would point out that (a) nobody suggested that addresses be gotten 
from IANA, and (b) globally unique addressses WERE the norm prior to the 
addressing shortage that precipitated RFC 1597.

Also, the methods of peer-to-peer you mentioned involve a server. 
That's not peer to peer.  Think telephones with IP addresses when you 
think about peer to peer.  The fewer NATs you have the more reliable 
those conversations will be.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Mar 2003 08:58:34 -0800

Eliot

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 14:07:49 -0500

In message <[email-masked]>
, "Manfredi, Albert E" writes:
> If the entire peer-peer network is behind the NAT, the NAT won't bother it in
>  the slightest. That was the scenario I was describing. Multiple such systems
> , installed in many different sites, all of them internally identical.

But then you need to assign addresses within the private address
block.  Identical addresses cannot be assigned at the factory.  If
some widgets take on server roles their addresses must be well known.

> If there is a server outside the NAT, once again, the peer-peer network can r
> emain identical in all instances and the NAT will take care of making the ser
> ver appear identical to all hosts inside the NAT.
> 
> Comms outside the NAT may be expected to be infrequent, e.g. primarily for oc
> casional remote system monitoring or remote troubleshooting. And these sessio
> ns may always be initiated outside the NAT, leaving the peer-peer network unc
> hangerd in every case. 

If you are replicating a cluster of processors, in which there are a
small number of processors each with a role, an initial address can be
assigned from *your address spec* for initialization.  With each
initialization, each processor can learn its real address.  No NAT,
just an address learned in the boot process.

If the application is making a hew hundred planes, all with the same N
processors on them, then only one has to have an address configured on
it (just like the NAT would have to have an address configured) and it
could provide addresses to the others.  The initialization addresses
could be arranged to be not routeable outside of the network segment
(plane).  Each plane has a unique address.  Each component within the
plane has a unique address.  Only N (a small number) of addresses must
be reused within the provider address block.

The IPv6 autoconfig can be that method of initialization unless
security requirements dictate use of something else.

> My problem with all the arguments against a private address space in IPv6, an
> d all the arguments in RFC 1627 too for that matter, is that these arguments 
> assume the only motivation is to economize on address space. And yet, plenty 
> of people have indicated otherwise.
> 
> Yes, it is always possible to create private networks with real but illegal g
> lobal addresses. That's a nuisance and prone to creating problems. And I don'
> t think that IPv6, by design, should make it mandatory for every private netw
> ork to obtain globally unique addresses from the IANA. That's sort of obnoxio
> us.
> 
> Bert

You can also create private addresses by reusing allocated addresses
multiple times if that's all you want to do.  That assumes you have
some allocated address space and want to reuse a subset of it.

Problems with the registries overcharging for IPv6 address space
(selling sand in the desert at a very high price being the going
analogy) are a separate issue.  However since it is a very real issue,
it may be worth keeping the existing IPv6 private address space block
until such time as that issue is resolved, then depricating it.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 25 Mar 2003 14:07:49 -0500

Curtis

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2003 11:17:53 -0800

Eliot,

On Tuesday, March 25, 2003, at 08:58  AM, Eliot Lear wrote:
> from IANA, and (b) globally unique addressses WERE the norm prior to 
> the addressing shortage that precipitated RFC 1597.

Just to be clear, it wasn't only a perceived address shortage that 
precipitated 1597, it was also the need for folks to move to provider 
based addressing.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 25 Mar 2003 11:17:53 -0800

Eliot,

Rgds,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Mar 2003 11:31:28 -0800

[Working backwards]

> precipitated 1597, it was also the need for folks to move to provider 

Only in as much as people began to use NATs to isolate themselves from 
having to renumber.  Fix the renumbering problem and all of this goes 
away.  Don't fix the renumbering problem and IPv6 isn't ready for prime 
time with or without site-locals.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Mar 2003 11:31:28 -0800

[Working backwards]

Eliot

---

From: Jing Shen <[email-masked]>
Date: Wed, 26 Mar 2003 10:49:16 +0800 (CST)

>from IANA,

But if you want to avoid address overlaping between private network and public network, it is required to renumber internal computers even if  they do not want to set up servers. So,  it is asked to apply address from either ISP or IANA. My question is:  Why and how could we add such a mandotary requirement?

> and (b) globally unique addressses WERE the norm prior to the 

IMHO, any standard should consider backward compatiblity. Many organizations have use IPv4 private address in their internal networks. When these networks are upgraded to IPv6,  we should define an upgrading mechanism as smooth as possible. If all those private address of 10.0.0.0/8 are mapped to the same IPv6 block, people may be reluctant to do all those changes but resort to NAT. And, could DHCP be applied to a large network with low cost? 

To telephone application, why should we use software solution but not use IP-phone service provided by telephone companies?

regards

Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, ZheJiang Province 310027
P.R.China

---------------------------------
Do You Yahoo!?
"雅虎通网络KTV, 随时随地免费卡拉OK~~"

---

From: Jing Shen <[email-masked]>
Date: Wed, 26 Mar 2003 10:49:16 +0800 (CST)

regards

Jing Shen

State Key Lab of CAD&CG