[153952] in North American Network Operators' Group
Re: IPv6 /64 links (was Re: ipv6 book recommendations?)
daemon@ATHENA.MIT.EDU (Masataka Ohta)
Tue Jun 19 09:29:53 2012
Date: Tue, 19 Jun 2012 22:28:11 +0900
From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
To: Owen DeLong <owen@delong.com>
In-Reply-To: <3AFDBCF3-F34F-48EE-A714-ECF419EB3C9A@delong.com>
Cc: nanog@nanog.org, davehart_gmail_exchange_tee@davehart.net
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Owen DeLong wrote:
> Showing that you don't actually understand what everyone else means when
> they say "end-to-end".
Where is your point only to demonstrate that you don't understand
what"end to end" means?
> No carrier is going to implement that for obvious reasons.
>
> Besides, that's not transparent end-to-end, that's predictably opaque
> end-to-end.
With no reasoning of you, I can simply say:
WRONG
>> UPnP provides information for clients to restore IP and TCP
>> headers from local ones back to global ones, which is visible
>> to applications.
> But it doesn't work across multiple layers of NAT.
It is trivially easy to make UPnP works across multiple layers
of UPnP capable NAT.
> Now, redraw the diagram for the real world scenario:
>
> host <-> UPnP NAT <-> Carrier NAT <-> Internet <-> Carrier NAT <-> UPnP NAT <-> host
>
> Tell me again how the application signaling from UPnP survives through all that and comes up with correct answers?
It is trivially:
host <-> home UPnP NAT <-> Carrier UPnP NAT <-> Internet
<-> Carrier UPnP NAT <-> home UPnP NAT <-> host
Masataka Ohta
