Re: [v6ops] [OPSAWG] Heads Up - Need to clarify the issue

On 11/11/10 10:39 PM, Chris Donley wrote:
> Thanks Richard.
> 
> A few points: a) This is not a question regarding whether to deploy
> NAT444. That decision has already been made, and in many cases,
> NAT444 will be used. It's also not a question about IPv6 - IPv6 will
> be deployed ASAP. The question is how to deploy NAT444 in a way that
> is most beneficial for most people. b) There are also other
> differences wrt RFC1918.  Importantly, some very popular home
> gateways don't accept RFC1918 space on the WAN interface.

Ok, that's interesting case, got a model you can site when claiming that
they won't accept an rfc 1918 address on the wan interface?

The draft does not claim that and I know of no device which fits that
description. overlapping inside and outside prefix collisions where what
this draft was proposing to fix with this assignment.

> c) we'd
> like an /8, we think we can make a /10 work.
> 
> Chris -----Original Message----- From: [email protected]
> [mailto:[email protected]] On Behalf Of Richard Hartmann Sent:
> Thursday, November 11, 2010 4:23 AM To: Christopher LILJENSTOLPE Cc:
> IPv6 Operations; [email protected]; [email protected] Subject: Re:
> [v6ops] [OPSAWG] Heads Up - Need to clarify the issue
> 
> On Thu, Nov 11, 2010 at 11:19, Christopher LILJENSTOLPE 
> <[email protected]> wrote:
> 
>> Is it not globally unique, yes, is it unfettered in it's use (i.e.
>> 1918), then no.  Joel, if you are defining as being 1918-like
>> (whatever that is) is simply !global_routing_table, then it's like
>> 1918, just as the rest of the bogon list, e space, 127/8, 0/8, etc.
>> Please read the last draft as to how the MUSTs and SHOULDs are
>> defined.  It IS different for some values of different.
> 
> 
> FWIW, I agree with Joel that for all intents and purposes, this is 
> additional RFC1918 space. The only two differences are that
> 
> a) It's not already in use. Thus, everyone can use it no matter if 
> RFC1918 is already used up in their relative networks. b) You should
> not use it for documentation purposes.
> 
> I am still not convinced NAT444 is a good idea as if will simply 
> prolong the inevitable pain while replacing some specific problems 
> that can be fixed locally (need to upgrade core & cpe devices) with 
> problems that affect people who can't fix them (no connectivity to 
> people who made the transition, breaking the end-to-end assumption
> on a huge scale).
> 
> As has been pointed out repeatedly, a /10 is not enough for
> reasonably large networks, anyway. 224/4 might cut it for most ISPs
> but that address space is permanently useless for obvious reasons.
> Unless someone comes up with a _new_ use for that IPv4 space. Which
> sounds somewhat unlikely.
> 
> 
> NAT444 will create even _more_ incentive to not transition quickly. 
> And it will convince even more people that the whole IPv6 issue is 
> made up and that IPv4 will live forever.
> 
> 
> Richard _______________________________________________ v6ops mailing
> list [email protected] https://www.ietf.org/mailman/listinfo/v6ops 
> _______________________________________________ v6ops mailing list 
> [email protected] https://www.ietf.org/mailman/listinfo/v6ops
>