RE: ocean: do not boil

["Tony Hain" <alh-ietf@tndh.net>]

Margaret Wasserman wrote:
> Hi Tony,
> 
> >The most obvious case at the moment is the substantial deployment of 
> >IPv4-only NAT CPE that for financial reasons *will not be upgraded* 
> >until the ISP is ready to provide native IPv6 support (in 
> North America 
> >that is looking like ~2006, or in the case of docsis devices much 
> >later). For those end sites that want to move sooner, and 
> don't have a 
> >reasonable option for an alternate ISP, just saying we only support 
> >dual stack is telling them they can't use IPv6 capable apps & 
> >appliances for at least 5 years.
> 
> I'm not sure how this follows from Randy's comments...

>> if i want my web site seen by both v4 and v6 users, then i can
connect 
>> it to v4 and v6 space and run dual stack.  in fact, i do so today.  
>> as v6 deploys, folk every useful site will do so.

Asserts that if a content site wants to be seen as IPv6 that it is in
control and can just advertise that and all IPv6-only nodes will be able
to reach it. The reality is that a consumer behind an IPv4-only NAT CPE
will need some form of IPv6-over-foo to get past the CPE. The hidden and
invalid assumption in Randy's comment is that the IPv6 network is
contiguous. 


> 
> If a node in the end site wants to access an IPv6-only 
> service, the user would need to install IPv6 on that node (or 
> buy a new appliance with IPv6 included, etc.).  If the IPv6 
> infrastructure isn't present to route IPv6 natively, then 
> they might use one of our several tunneling mechanisms to 
> tunnel the packet over the IPv4 infrastructure to an IPv6 network.

This is specifically what Randy's note was asserting, that we don't need
the complexity that the mechanisms bring to the table. 

> 
> >Also, as a meta point, declaring an approach for transition out of 
> >scope before the scenario documents are done is just a bit short 
> >sighted.
> 
> I actually think that we were discussing some prioritization 
> of the scenarios, not declaring any of the solutions in or 
> out of scope.

>> trying to make pure v4 sites/hosts communicate for arbitrary services
with pure 
>> v6 sites/hosts and vice verse is a nice way to make the problem
vastly more
>> complicated, the solutions vastly more complex, and the net much less
reliable.
>> let's not go there.

Sounds like precluding a class of transition scenarios to me.

> 
> Once we have a full set of scenarios, I think it will make 
> sense to try to trim down the set of scenarios, based on what 
> we think is most likely to occur.
> 

This is absolutely silly. The whole exercise is designed to refocus on
the scenarios that are actively being deployed, or currently on the
drawing board for deployment. Claiming that we can out guess the market
acceptance of those and whittle that down further presumes access to a
crystal ball I haven't seen yet. Prioritizing based on relative broad
applicability would make sense if there were limited resources, but we
seem to have plenty of interested participants. Developing them in
parallel doesn't appear to be a problem, so why artificially restrict
the working set? 

Tony


> Margaret
> 
>