[arin-ppml] An article of interest to the community....

[Mike Burns]

Hi Paul,

>> I think this worship of end-to-end connectivity has to stop.
>> It's an idealistic view of the Internet that is incompatible with
>> reality. I don't even hold with the idea that end-to-end was ever
>> that important. ...
>
> I suggest that if you want to promote a non-end-to-end model you should
> write and speak very much more widely than just posting to the ARIN
> PPML.  In particular I suggest that you reach out to the IETF and
> especially the IAB.
>
> See also Itojun's remarks on the matter:
>
> http://ipv6samurais.com/ipv6samurais/demystified/end-to-end-principle.html
>
>
My point is that due to widespread Nat use and early ALG use in the proto 
Internet that end-to-end never truly meant unmanipulated packets traversed 
from one machine to another. What it meant was that another endpoint, at a 
higher level on the OSI model, was what was meant by an end. Like email at 
the application level. Researchers did not want to be able to communicate 
only with their colleagues in their own school, they wanted all researchers, 
nationally and eventually world-wide, to be able to communicate, and in fact 
this occurred in the early net through the use of gateways which could take 
text information from a computer running one operating system and network 
protocol to another computer running a different operatings system and a 
different protocol. I was using such a system with my ARPANET account as 
far back as 1978. When tcp/ip was later installed on every machine, there 
was a point in time where packets could do end-to-end traversal unmolested, 
and shortly thereafter the dangers of that became evident, firewalls were 
erected, and packet level end-to-end was no longer a reality. However, that 
didn't stop the rise of voip, video, gaming, etc., so the argument that IPv6 
is better because it restores packet-based end-to-end and thus will allow 
for new applications is specious to me.

>
> My experience of history differs significantly from your accounting
> here.  I'm not disagreeing with you that most hosts are behind
> firewalls.  I've used NAT sometimes to effect a security policy.  But I
> am very glad that this is left to me as an option, and that it's not
> a mandatory part of the architecture of all networks, and that I can
> move to different specific solutions as time goes by, knowing that the
> packet based end to end connectivity model will be my building block.
>

Your packets will not arrive at their intended destination without having to 
traverse some kind of stateful inspection and/or port manipulation.
Application designers know that and have created workarounds which take into 
account people's desire for security and their desire to absolutely prevent 
end-to-end packet traversal, due to the inherent dangers of that.

>> ...
>> I asked Mr. Vixie what applications he thought were being prevented
>> by NAT, and did not get an answer. ...

I asked the question after you asserted that such applications were being 
prevented.

>
> My apologies for this oversight.  My answer is: we cannot know because
> those applications never existed.

Which was the point of my question, how can you assert this prevention when 
you simply cannot know?

 If your question was, what
> applications did I personally investigate until I was stopped by NAT, I
> could answer.  I think NAT could be made robust enough for the kind of
> datagram (voice, gaming, kerberos) applications I'd like more of, for
> example we could arrange some kind of gateway RPC protocol so that an
> application could learn the IP address and UDP port number that its
> distant peers will see when we transmit toward them.  Making that kind
> of thing work portably across all platforms is as large a problem
> statement as just deploying IPv6, however.
>

I disagree, and probably because I think deploying IPv6 is a huge problem, 
and after 12  years we have an Internet which is still 99.7% Ipv4, which I 
think underlies the extent of this problem.

>> If I could pick up my magic wand again and replace IPv4 with IPv6 in
>> toto, I don't believe there would be any new applications taking
>> advantage of end-to-end, because people would be too busy getting
>> their IPv6 firewalls to work.
>
> I would never want to take away the option of running firewalls or NAT
> or ALG.  One of the beneficial aspects of the packet based end to end
> architecture of the Internet is that it makes such technologies possible
> for those who want them.  I don't think that such tools could have been
> created had the world adopted a global virtual circuit standard for
> internetworking rather than a global packet standard like we have now.
> In fact I believe that the flexibility of the end to end packet model
> was the key strength that allowed it to outcompete other proposals.

I agree with you here. I think the global packet standard created the 
situation which led to widespread adoption of the Internet. But that was a 
phase of evolution which led eventually to the understanding that allowing 
any computer on the globe unfettered packet based access to every other was 
simply too dangerous and had to be prevented. There have been many exciting 
and new applications developed and deployed in the Nat/firewall phase, 
however, once application designers understood the security topology of the 
Internet.
>
>
> My unwillingness to attempt to prove a negative should not be taken as
> agreement by me that we should be talking about the relative merits of
> currently imaginable applications rather than the design strengths of
> the underlying model.

If you cannot prove a negative, then it should not be used as an assertion 
in support of IPv6, which started this.

>
>> Our job at ARIN is not to push protocols based on a nearly religious
>> view of the optimum network architecture. We are charged with
>> carefully doling out the free pool addresses entrusted to us, trying
>> to control route table growth, and ensuring the unique public
>> registration of all addresses.
>
> On this point I agree with you 100%.  And if you can think of a policy
> change which will make ARIN better at those functions, I encourage you
> to write it up and submit it to the policy development process.
> -- 
> Paul Vixie
>

Done. I have thoughtfully named it Prop-151.

Regards,
Mike