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

From: Rémi Després <[email-masked]>
Date: Thu, 11 Nov 2010 17:12:27 +0800

Le 9 nov. 2010 à 10:29, Fred Baker a écrit :

> Chris Liljenstolpe has a proposal that he made in ops-area today, for a mechanism to create what amounts to an RFC 1918 prefix, but specifically for use in NAT444 ISP configurations.

Some comments object the idea because it is understood as one more RFC1918 prefix.
Could you confirm (or invalidate) this understanding:

"The request if for ONE /8 (not more, not less) to be NEITHER in RFC 1918 NOR in the global address space."

If it is different, could you explain what it is?

Thanks,
RD

> It involves a request to the ARIN board. He will write a quick draft and post it this week, discuss this Thursday in the Ops WG, and call the question in Friday's v6ops meeting. Due to the real time nature of the discussion, I'll ask folks to be aware and follow it.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "George, Wes E IV [NTK]" <[email-masked]>
Date: Thu, 11 Nov 2010 09:18:08 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rémi Després
Sent: Thursday, November 11, 2010 5:12 PM
To: Chris Liljenstolpe
Cc: IPv6 Operations; [email-masked]; [email-masked]
Subject: [v6ops] Heads Up - Need to clarify the issue

"The request if for ONE /8 (not more, not less) to be NEITHER in RFC 1918
NOR in the global address space."

[Wes]
read the draft.

http://tools.ietf.org/html/draft-weil-shared-transition-space-request-01

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 11 Nov 2010 17:29:34 +0800

On 11/11/10 5:12 PM, Rémi Després wrote:
>> Chris Liljenstolpe has a proposal that he made in ops-area today,
>> for a mechanism to create what amounts to an RFC 1918 prefix, but
>> specifically for use in NAT444 ISP configurations.
> 
> Some comments object the idea because it is understood as one more
> RFC1918 prefix. Could you confirm (or invalidate) this
> understanding:
> 

I believe my characterization of the prefix as a special use ipv4
address prefix (as are rfc 1918 address blocks) is accurate.

The use is rfc-1918-like but the folks who believe that they need it
would like to tell you not to use it for that purpose.

> Thanks, RD
> 
> 
> 
> 
>> It involves a request to the ARIN board. He will write a quick
>> draft and post it this week, discuss this Thursday in the Ops WG,
>> and call the question in Friday's v6ops meeting. Due to the real
>> time nature of the discussion, I'll ask folks to be aware and
>> follow it. _______________________________________________ v6ops
>> mailing list [email-masked] 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:16:16 +1100

> "The request if for ONE /8 (not more, not less) to be NEITHER in RFC 1918 NOR in the global address space."

You are correct, Rémi.

> OPS-AREA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-area
> 

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Thu, 11 Nov 2010 21:19:55 +1100

> would like to tell you not to use it for that purpose.

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.
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
> 

---
李柯睿
Check my PGP key here:

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 11 Nov 2010 18:32:15 +0800

On 11/11/10 6:19 PM, Christopher LILJENSTOLPE 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.

I'm not sure if you're correcting me or clarifying my observation. I've
read that draft and I don't believe what I've described is incorrect.

In terms of using the term special use ipv4 prefix the term is well
understood, see for example rfc 3330 and the v6 equivalent in 5156.

---

From: Richard Hartmann <[email-masked]>
Date: Thu, 11 Nov 2010 12:23:25 +0100

On Thu, Nov 11, 2010 at 11:19, Christopher LILJENSTOLPE
<[email-masked]> 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

---

From: Chris Donley <[email-masked]>
Date: Thu, 11 Nov 2010 07:39:17 -0700

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.
c) we'd like an /8, we think we can make a /10 work.

Chris
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Hartmann
Sent: Thursday, November 11, 2010 4:23 AM
To: Christopher LILJENSTOLPE
Cc: IPv6 Operations; [email-masked]; [email-masked]
Subject: Re: [v6ops] [OPSAWG] Heads Up - Need to clarify the issue

Richard

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 12 Nov 2010 09:47:12 +0800

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-masked]
> [mailto:[email-masked]] On Behalf Of Richard Hartmann Sent:
> Thursday, November 11, 2010 4:23 AM To: Christopher LILJENSTOLPE Cc:
> IPv6 Operations; [email-masked]; [email-masked] Subject: Re:
> [v6ops] [OPSAWG] Heads Up - Need to clarify the issue
> 
>> 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.
> 
> 
> RFC1918 is already used up in their relative networks. b) You should
> not use it for documentation purposes.
> 
> 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.
> 
> 
> Richard _______________________________________________ v6ops mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops