Re: [OPS-AREA] [OPSAWG] Heads up - Plea for allocating a /8 to ISPs

On Fri, Nov 12, 2010 at 11:24 AM, Christopher LILJENSTOLPE
<[email protected]> wrote:
> Ok James,
>
>
>
>
> On 13Nov2010, at 03.57, james woodyatt wrote:
>
> On Nov 11, 2010, at 22:42, Christopher LILJENSTOLPE wrote:
>
> I'm fine with discussion of the merits (or demerits) of the draft.  I am NOT
> okay with folks who have not actually been involved in the discussions, or
> personally know the individuals impune their motives. [...]
>
> I don't think I've impugned anyone's motives, and it's not my intention to
> provoke a defensive response.  My sincere apologies, if I did.  I'll
> redouble my efforts to maintain a collegial tone.
>
> I accept your apology.  Let's move on...
>
> I'm responding to what the authors of the draft spent over half their word
> count spelling out in Section 2, "Motivation."  I don't believe I've implied
> that their motives are dishonest, but I continue to be concerned less about
> what the authors are saying and much more about what the authors are leaving
> unsaid.
>
> As I have said before, and I continue to maintain, the authors have not been
> forthcoming with either A) an accounting of what systems are known, or can
> be discovered in the reasonable future, to be broken under NAT444
> deployments by using the non-RFC1918 private address realms the draft is
> intended to support, or B) a discussion of what CPE implementors are
> expected to do in the future with the prefix reserved by IANA from this
> draft.
>
> As to your other topics, I, for one, would only deploy this space, and
> NAT444 against heritage CPE.  I have no intent of deploying once I have
> functional CPE in the field that can deal with v4 and v6 end-nodes in a v4
> exhausted world (i.e. IVI, DSLite, etc).  If we had that equipment from
> vendors today, and it was deployed, we wouldn't be having this conversation.
>  Therefore, the question should be, what will the effects be on EXISTING
> CPE, as new CPE should not be subject to this mistreatment.
>
> I contend that if IETF is to take this individual submission seriously, then
> both of those items need to be discussed in the draft.  This is important
> because it isn't just operators who have limited resources for IPv6
> transition engineering.  CPE implementors do too, and every person-hour of
> labor spent on engineering, qualifying and distributing changes to CPE
> software to cope with the damage operators do to IPv4 service by deploying
> non-RFC1918 private address realms to CPE hosts and gateways is energy that
> could be better spent on furthering the IPv6 transition instead
>
> I would also point out to many folks who discussed this in the room today in
> regards to lengthy deployments of v6, no one has done that in a v4 exhausted
> world (because it hasn't happened yet).  Some service areas may have CE

IMHO, I would say mobile in North America looks pretty much like IPv4
exhaust already happened. All the major service providers have
compromised IP networks in some way.  They all do NAT44 today.  They
use BOGONs and overlapping address spaces, multiple instances of
RFC1918.... that's today.  There are also committed IPv6-only + NAT64
and Gi-Ds-lite deployments being deployed now.

So, there is an IPv4 exhaust model already live and "working".  It can
keep going as is, it does not get easier, but the mobile networks in
North America are not bounding their growth by available IPv4.

Cameron

> (Consumer electronics) and other end-nodes that are v6 capable, but I do
> know that that is not the case in my service area, nor in our recent hosts
> service area, nor in many service areas in other parts of the world.
>  Carriers are going to have to deal with this in SOME way with existing
> deployed CPE/RG until such a time as they can be replaced.  That is going to

Yep, nobody's getting free phones for the purpose IPv6, they just
don't get public IPv4 addresses or end to end connectivity.


> be variable as to how many RG/CPE there are, who owns them, and, certainly
> as important, when we actually have CPE that does the "right" thing to
> deploy.  Until that, we can either do something ugly, or stick our heads in
> the sand and pretend things aren't going to break.
> As far as the level of energy to deploy those addresses to the WAN side of
> CPE - that will be low compared to the energy necessary when v4 CE equipment
> starts failing.
> Chris
>
>
> --
> james woodyatt <[email protected]>
> member of technical staff, communications engineering
>
>
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>
>
> ---
> 李柯睿
> Check my PGP key here:
> https://www.asgaard.org/~cdl/cdl.asc
>
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops