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

Re: Rewriting/ingress filtering/NAT/proxy, was: Re: Shim6 Agenda for IETF 71

On 5 mrt 2008, at 0:57, Brian E Carpenter wrote:
The new top 64 bits of the address are checksum-equivalent to the old top 64 bits. (As long as it's /48 prefixes this is fairly trivial to do.)
I'm confused. Didn't you just steal all the site's subnet addressing bits? 

I just borrow them.  :-)
For instance, if I use 20:21:22:23 locally and then I get prefix 10:11:12 from my ISP, then 20+21+22+23 = 10+11+12+X so X = 20+21+22+23-10-11-12 = 56 so my globally visible subnet is 10:11:12:56. Then, when a packet returns and is translated back, we do the whole business in reverse and 20:21:22:23 reemerges.
This would be a relatively clean type of NAT, the only thing that it breaks is referrals. 


Doesn't it also break any upper-layer embedding of IP addresses?
What about MIBs containing addresses, for example?
Wouldn't that be classifyable as "referrals", too? I do agree this breaks those. However, in many cases, this can be compensated for by the application finding out a global address and embedding that address. This is one of the steps in IPv4 NAT traversal and as far as I know, certainly not the hardest.
Also, breaking referrals means we can't escape from today's need to build p2p systems using some other namespace than IP addresses. That doesn't seem 
like what we wanted to achieve.
Well, if it's a choice between this and a scalable internet with global addressability and reachability, then I'd choose the latter. But if it's a choice between this and a non-scalable internet with global addressability (with possible reachability trouble because of the non-scaling) and a scalable internet without global addressability or reachability because of port overloading NATs, I'd probably choose this solution rather than either alternative. I'm not entirely sure these are our choices, though.
Now combine this with the shim6 proxy, address rewriting and ingress filtering stuff and you may end up with something like this: 


I think that a really interesting discussion is whether it's
possible to merge some of the ideas in draft-rja-ilnp-intro-00.txt
with shim6.


Sigh. Can't we just take 8+8/GSE out back and shoot it already?
The RRG should know better than to shoehorn new ideas in existing packet formats. That's what we do over at the IETF. What we need is a clean loc/id architecture, that shows how locators can easily be renumbered because people won't be tempted to put them into their firewalls, shows how to get locators from identifiers in a scalable way that's fast enough and how the security is done. That's all stuff that's missing from 8+8/GSE. Ran's new take on this is a bit better than that, but only in an incremental way, fundamentally it's still the same tired idea.