[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] thoughts on the design space 4: encapsulate vs. translate
- To: rrg <firstname.lastname@example.org>
- Subject: [RRG] thoughts on the design space 4: encapsulate vs. translate
- From: Jari Arkko <email@example.com>
- Date: Thu, 24 Jul 2008 15:23:58 +0300
- User-agent: Thunderbird 220.127.116.11 (X11/20080505)
My other conclusions relate to the choice between encapsulation and
First, I think we need to consider this choice in the context of the
entire functionality, including interworking with the legacy Internet. I
like the proxy encapsulator (PTR) design, and would far prefer that to
translation. However, as discussed before its unclear if this is
deployable due to incentive issues. For the moment, that leaves
translation as the deployable interworking scheme.
I do not care much whether the upgraded-to-upgrade traffic uses
encapsulation or translation. That's a detail in many ways.
So for the moment this leaves me with the following "best" design:
1. Employ something like NERD for the mapping table, no caching
2. Identifier spaces are allocated per organization, PI style, and we do
not attempt to solve the host identifier-locator split
3. Translate or encapsulate when talking from an upgraded network to
another upgraded network
4. Translate when talking to a legacy network
While this is "best" solution in my today's opinion, the big question in
my mind is whether it is good enough, and what the drawbacks are. I
understand that Christian has been making some progress in eliminating
some NAT effects from translation design when using IPv6. However, how
significant are the remaining ones? I share the concerns with Brian.
Also, the entire system has a number of other implications, such as
effects to referrals, and increased complexity.
to unsubscribe send a message to firstname.lastname@example.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg