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

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 (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 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

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