[address-policy-wg] Mandating NAT toward the final /8
- Previous message (by thread): [address-policy-wg] Mandating NAT toward the final /8
- Next message (by thread): [address-policy-wg] Mandating NAT toward the final /8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
TJ
trejrco at gmail.com
Fri Jul 17 05:02:56 CEST 2009
"IPv6 will not be deployed soon" Brusque manner aside, I would be curious to know how you define "deployed". Is it alive, in production networks today? Yes. Are there _many_ organizations moving towards that goal? Yes. Obviously, it is not as widely deployed as IPv4 - but why should a current failing of our industry as a whole (getting IPv6 more available, sooner) encourage the yet-more-widespread use of a previous failing (loss of addresses as meaningful, unique identifiers)? Is some form of NAT going to be required - probably yes, but that is an unfortunate side-effect of the "current failing" I mentioned ... rather than being a noble goal unto itself. (For what it is worth - I have no problem with the idea of bringing some form of end-to-end'edness into NAT - whatever the mechanism, as long as it can be readily supported and doesn't pose any overwhelming security concerns of its own. I do, however, have a problem with it being forced down a network's throat. You imply that you have seen counter-arguments to "NAT can be harmless" - care to share?) /TJ >-----Original Message----- >From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- >admin at ripe.net] On Behalf Of Masataka Ohta >Sent: Thursday, July 16, 2009 6:56 PM >To: Sander Steffann >Cc: Sascha Lenz; address-policy-wg at ripe.net >Subject: Re: [address-policy-wg] Mandating NAT toward the final /8 > >Sander Steffann wrote: > >> Hello Masataka, > >Hello. To summarize the discussion, my points are: > > IPv6 will not be deployed soon > > NAT is inevitable > > NAT can be harmless > >and I have seen no counter argument for the first two points. > >> The document you sent to this list is only a draft. > >For IPv6 deployment, there are abandoned RFCs, which means being an RFC does >not mean anything, and new drafts with NAT are coming, some of which needs >changes in hosts. > >> The chances of >> getting end to end NAT globally deployed before the IPv4 address space >> runs out are very close to zero, > >That's not my proposal, I just say "Mandating NAT", including legacy NAT, >though those who want to make NAT end to end transparent may use end to end NAT >or similar technologies. > >I heard that UPnP is supporting transparent TCP (only TCP), which seems to be, >as transparent as end to end NAT, of course with host modifications. > >Instead, your statement mean > >> The chances of >> getting IPv6 globally deployed before the IPv4 address space runs out >> are very close to zero, > >or, considering technical quality of IPv6 specification, exactly zero, which >means we must use IPv4 NAT. > >My proposal gives a way to make NAT harmless. > >> Also remember that we make policy for all uses of IP addresses, not >> just end user networks that have/get/need a limited amount of public >> addresses. These policies also apply to datacenters where servers are >> hosted. There are many examples where you can not put those servers >> behind a NAT box. Mandating NAT in the way you have stated in your >> messages is therefore not possible. > >What's the rational for data centers not to reduce amount of IP address >consumption by not accepting virtual servers when IPv4 address is becoming >scares and IPv6 is not ready? > >> We are not going to change address policy in the whole RIPE region >> because of a draft document that only covers a part of what addresses >> are used for. > >See above on the consequence of your reasoning that IPv6 will not be deployed >soon and NAT is inevitable, which, so far, has nothing to do with my draft. > > Masataka Ohta
- Previous message (by thread): [address-policy-wg] Mandating NAT toward the final /8
- Next message (by thread): [address-policy-wg] Mandating NAT toward the final /8
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]