[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-v6ops-nap-00.txt & NAT security [2.2]



Hi Gunter, Fred,

On Wed, 25 May 2005 08:59:19 -0700
Fred Baker <fred@cisco.com> wrote:

<snip>
> 
> Regarding disruptiveness, when we talk about disruptive technologies,  
> it is not that the network ceases working that is disruptive;  
> businesses are disrupted. In the IPv6 deployment, the disruptive  
> aspects for ISPs are that they have to upgrade equipment (perhaps  
> hardware, surely software), which involves a testing effort and  
> involves figuring out the best configurations for what they are trying  
> to do. That deployment, even if the software is free and no hardware  
> changes are required, can be pretty expensive. This is why the ISPs  
> have been so willing to slow-roll the roll-out - they want to know that  
> the money they expend is going to result in adequate ROI. And frankly,  
> something that deploys in parallel and gives no added benefit is not  
> going to convince consumers to buy, and therefore has limited ROI. So  
> for the IPv6 roll-out to succeed, there actually has to be a disruption  
> of some kind - either new services available as a result, or a change  
> in the ISP cost model, or new applications available to consumers that  
> would not otherwise be available, or something.
> 

<snip>

Fred covered well a number of the other "non-technical" disruptiveness
factors that deploying new technologies like IPv6 creates. My
"disruptiveness" is a subset of Fred's business costs. 

To clarify the disuptiveness I was trying to describe, network
administrators will have to put some effort into learning IPv6, to learn
things such as the formatting and structure of addresses, ICMP based
neighbour discovery etc. - the technical details of IPv6. Because effort
has to be put into learning IPv6, while the network administrator is in
"learning new-stuff mode", it can also be a good opportunity introduce
or re-introduce broader conceptual ideas such the benefits of
end-to-end, etc. Opportunities to start with a "clean conceptual slate"
are relatively rare, so when they occur (as it will with IPv6), I think
it is good to try to take as much advantage of them as is possible and
practical. IPv6 is both similar and different to IPv4. The similarities
help to learn IPv6, the differences need to be explained well so that
people can see the advantages in deploying IPv6 and therefore also learn
and understand why leaving behind the "warts" of IPv4 today (e.g., NAT)
are part of IPv6's advantages. I certainly think the NAP draft is
covering these topics, my interest is just to try to ensure that the
"warts" of IPv4 are hopefully fully "explained" away from being deployed
in IPv6.

Regards,
Mark.