Subject: IPsec thing with REAP

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 10 Mar 2008 13:22:25 -0400

This is what I just mentioned, would be useful to include this in more  
general IPsec-shim6 discussions.

Additional text for the security considerations:

To protect against spoofed keepalive packets, a host implementing both  
shim6 and IPsec MAY ignore incoming REAP keepalives if it has good  
reason to assume that the other side will be sending IPsec-protected  
return traffic. I.e., if a host is sending TCP data, it can reasonably  
expect to receive TCP ACKs in return. If no IPsec-protected ACKs come  
back but unprotected keepalives do, this could be the result from an  
attacker trying to hide broken connectivity.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Mar 2008 13:31:54 -0400

OK, I added this text to the draft.

Jari

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Mar 2008 19:48:31 +0200 (EET)

On Mon, 10 Mar 2008, Iljitsch van Beijnum wrote:
> To protect against spoofed keepalive packets, a host implementing both shim6 
> and IPsec MAY ignore incoming REAP keepalives if it has good reason to assume 
> that the other side will be sending IPsec-protected return traffic. I.e., if 
> a host is sending TCP data, it can reasonably expect to receive TCP ACKs in 
> return. If no IPsec-protected ACKs come back but unprotected keepalives do, 
> this could be the result from an attacker trying to hide broken connectivity.

I wonder how actionable this is from an implementor point of view.

Does a REAP implementor have access to the IPsec and TCP data and 
state in example you gave?  How?` Even if there was such access, it's 
not obvious to make what kind of algorithm could be applied that would 
be reliable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Mar 2008 19:48:31 +0200 (EET)

---

From: Jari Arkko <[email-masked]>
Date: Mon, 10 Mar 2008 13:31:54 -0400

Jari

> attacker trying to hide broken connectivity.

Delivery-date: Wed, 12 Mar 2008 22:19:07 +0000
Date: Mon, 10 Mar 2008 13:31:54 -0400
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC:  [email-masked]
Subject: Re: IPsec thing with REAP

Jari

> attacker trying to hide broken connectivity.

Delivery-date: Wed, 12 Mar 2008 19:16:20 +0000
Date: Mon, 10 Mar 2008 19:48:31 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: [email-masked]
Subject: Re: IPsec thing with REAP

Delivery-date: Mon, 10 Mar 2008 17:49:14 +0000
Date: Mon, 10 Mar 2008 19:48:31 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
cc: [email-masked]
Subject: Re: IPsec thing with REAP

Delivery-date: Mon, 10 Mar 2008 17:41:57 +0000
Date: Mon, 10 Mar 2008 13:31:54 -0400
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC:  [email-masked]
Subject: Re: IPsec thing with REAP

Jari

> attacker trying to hide broken connectivity.

Delivery-date: Mon, 10 Mar 2008 17:23:21 +0000
From: Iljitsch van Beijnum <[email-masked]>
To: [email-masked]
Subject: IPsec thing with REAP
Date: Mon, 10 Mar 2008 13:22:25 -0400

Delivery-date: Mon, 10 Mar 2008 16:55:40 +0000
Content-class: urn:content-classes:message
Subject: FW: shim6 implementation posted
Date: Mon, 10 Mar 2008 09:54:23 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "shim6-wg" <[email-masked]>
Cc: =?iso-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>

FYI, we've just announced availability of another open source shim6 =
implementation (below).  =20

We haven't categorized the implementation according to Sebastien's =
implementation report draft, but our documentation has details about =
what is and isn't implemented.

- Tom

-----Original Message-----
From: Henderson, Thomas R=20
Sent: Monday, March 10, 2008 9:43 AM
To: [email-masked]'; =
[email-masked]'; =
[email-masked]'
Subject: shim6 implementation posted

We would like to announce a new set of packages at OpenHIP:  an initial =
shim6 [1] release.  shim6 stands for "Site Multihoming by IPv6 =
Intermediation" and is architecturally related to HIP.  Our shim6 =
implementation is a multithreaded C++ user-space process that interfaces =
with a standard Linux kernel (extended via loadable kernel modules).  =
Although we do not require kernel patches to support the shim, we do =
require specific kernel versions since the modules we are using do not =
have stable APIs across kernel releases.  This release is not ready for =
production use but implements many of the features of the shim6 protocol =
set. =20
=20
Software: http://sourceforge.net/project/showfiles.php?group_id=3D132288 =

Documentation: http://www.openhip.org/document.html

The shim6 release is also notable for OpenHIP because it marks the first =
steps towards a reorganization of the HIP software for improved =
modularity and isolation of platform specific components.  For instance, =
our implementation of the shim6 REAP protocol is designed to support =
also HIP, and we have started work on a HIP Abstraction Library (HAL) =
that provides platform-independent APIs for system interfaces common =
utilities such as checksum computations and message TLV construction.

We do not have a new HIP release at this time (the 0.5 release from =
October 2007 is still current) but our focus will shift now to =
implementing the HIP NAT traversal support. =20

If you are interested in contributing to the OpenHIP project or using =
the software, please visit our webpage at http://www.openhip.org and =
contact us.

- Tom Henderson and Jeff Ahrenholz

[1] http://www.ietf.org/html.charters/shim6-charter.html

Delivery-date: Mon, 10 Mar 2008 13:42:37 +0000
Date: Mon, 10 Mar 2008 00:40:32 -0400
From: Matthijs Mekking <[email-masked]>
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
CC: [email-masked]
Subject: Re: Question about pshim6

Hi Sébastien,

The shim6 meeting is in about 3 hours (1pm local time), so it has not
been discussed yet. Maybe you are able to follow it via jabber or m3u
(look at http://tools.ietf.org/agenda/71/).

I also found this paragraph troublesome, because putting the context
establishment before the data transfer would interfere with the initial
goal: Not require extra roundtrip up front to setup shim specific state.

For this reason, I agree that a pshim6 box should use the same heuristic
as in the original shim6 document.

Sébastien Barré wrote:
> Hi,
> 
> It may have been discussed during the meeting but I could not attend
> unfortunately.
> I have a question regarding this paragraph from section 3 of the draft :
> ---
> When H1 sends the first packet addressed to the CMULA of H2, the
>  packet is intercepted and processed by the P- Shim6 box of the
>  multihomed site.  The P-Shim6 box retains the data packet and
>  initiates the 4-way exchange to create a shim6 context with the
>  P-shim6 box of the peer network.  This exchange uses the PA addresses
>  as locators and the CMULAs as ULIDs.  Once that the shim6 context is
>  established between the local P-shim6 box and the remote P- Shim6
>  box, the local P-Shim6 box can forward the data packet with a shim6
>  payload header, referring to the established shim6 context.
> ---
> 
> I wonder why it would not be possible and more efficient to send the
> first data packet as soon as we know one locator for that packet.
> That is, I think we could use the same approach as host-based Shim6, in
> that the pshim6 box could perform the following steps :
> - the proxy of host H1 receives the first packet from H1 to H2. With the
> CMULA of H2 as destination address.
> - The proxy gets the corresponding locators, either from its cache or a
> reverse DNS lookup.
> - The proxy chooses one of the obtained locators as destination for the
> data packet, and immediately sends it. We thus send the packet 2RTTs
> earlier than in the current pshim6 approach.
> - The proxy applies some heuristic to decide if it initiates a Shim6
> negotiation, in the same fashion as host-based shim6.
> 
> Actually that approach is similar to what is proposed in the second
> option of section 7 (support for legacy sites and hosts). Indeed, what I
> propose is to behave as if the corresponding node were legacy, until we
> find it useful to use Shim6. Also, even if we decide to immediately
> start the shim6 negotiation, we can still do it in parallel with the
> data transfer, rather then before the data transfer.
> 
> Also note (if my understanding is correct) that in the case that both
> hosts in a communication use CMULAs, than the Shim6 negotiation is no
> longer required for providing transport layer survivability (There is
> only one CMULA candidate for rewriting an arriving packet, thus we do
> not need to ensure that one precise locator is used as ULID). OTOH,
> Shim6 is still useful for benefiting from the REAP protocol.
> 
> Am I missing something ?
> 
> regards,
> 
> Sébastien Barré.
> 

Delivery-date: Mon, 10 Mar 2008 11:01:01 +0000
Date: Mon, 10 Mar 2008 11:59:20 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: [email-masked], marcelo bagnulo braun <[email-masked]>
Subject: Question about pshim6

Hi,

It may have been discussed during the meeting but I could not attend 
unfortunately.
I have a question regarding this paragraph from section 3 of the draft :
---
When H1 sends the first packet addressed to the CMULA of H2, the
  packet is intercepted and processed by the P- Shim6 box of the
  multihomed site.  The P-Shim6 box retains the data packet and
  initiates the 4-way exchange to create a shim6 context with the
  P-shim6 box of the peer network.  This exchange uses the PA addresses
  as locators and the CMULAs as ULIDs.  Once that the shim6 context is
  established between the local P-shim6 box and the remote P- Shim6
  box, the local P-Shim6 box can forward the data packet with a shim6
  payload header, referring to the established shim6 context.
---

I wonder why it would not be possible and more efficient to send the 
first data packet as soon as we know one locator for that packet.
That is, I think we could use the same approach as host-based Shim6, in 
that the pshim6 box could perform the following steps :
- the proxy of host H1 receives the first packet from H1 to H2. With the 
CMULA of H2 as destination address.
- The proxy gets the corresponding locators, either from its cache or a 
reverse DNS lookup.
- The proxy chooses one of the obtained locators as destination for the 
data packet, and immediately sends it. We thus send the packet 2RTTs 
earlier than in the current pshim6 approach.
- The proxy applies some heuristic to decide if it initiates a Shim6 
negotiation, in the same fashion as host-based shim6.

Actually that approach is similar to what is proposed in the second 
option of section 7 (support for legacy sites and hosts). Indeed, what I 
propose is to behave as if the corresponding node were legacy, until we 
find it useful to use Shim6. Also, even if we decide to immediately 
start the shim6 negotiation, we can still do it in parallel with the 
data transfer, rather then before the data transfer.

Also note (if my understanding is correct) that in the case that both 
hosts in a communication use CMULAs, than the Shim6 negotiation is no 
longer required for providing transport layer survivability (There is 
only one CMULA candidate for rewriting an arriving packet, thus we do 
not need to ensure that one precise locator is used as ULID). OTOH, 
Shim6 is still useful for benefiting from the REAP protocol.

Am I missing something ?

regards,

Sébastien Barré.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

Delivery-date: Sat, 08 Mar 2008 22:18:52 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
To: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
Subject: Re: Rewriting/ingress filtering/NAT/proxy, was: Re: Shim6 Agenda for IETF 71
Date: Sat, 8 Mar 2008 17:16:57 -0500

On 6 mrt 2008, at 18:37, S=E9bastien Barr=E9 wrote:

> Iljitsch van Beijnum schreef:

Inderdaad!

>> When packets return, routers don't rewrite the destination address. =20=

>> Then, two things can happen: the packets end up at the host itself, =20=

>> which recognizes the rewriting and from then on, sources packets =20
>> with the source address that was written in the first packet by the =20=

>> router. Or hosts on the subnet are legacy and won't recognize the =20
>> rewriting, so a middlebox rewrites the destination address to the =20
>> unique site local prefix.

> This means that it is a requirement to have one of these three =20
> options (for packet return) :
> - All hosts are legacy (and the middlebox always rewrites)
> - All hosts recognize the rewriting (and the middlebox never rewrites)
> - some hosts are legacy, other not, but the middlebox must be aware =20=

> of the state of each host, so that it can selectively rewrite.

> Is it right ?

Yes, it is. This is a limitation that exists per-subnet. For each =20
subnet, you would have to choose one of these options.

>> The host or middlebox can now start shim6 so that if there is a =20
>> path failure, the session/context can move to a different address.

> Isn't there a possibility that a Shim6 context is established by =20
> both the middlebox and the host ? Or maybe this can be avoided by =20
> synchronizing the heuristics for Shim6 negotiation between the host =20=

> and the middlebox  ?

This is one of the things that must be worked out in a proxy shim6 =20
scheme. I'd say that a smart middlebox would recognize that a host can =20=

do shim6 itself and then get out of the way unless it's configured to =20=

overrule host-based shim6. In that case it could simply filter packets =20=

with the shim protocol in the protocol chain. The reason a proxy may =20
want to do this is that the site administrator desires centralized =20
control of traffic engineering decisions.

The next step would be for hosts to be aware of the proxies and work =20
together in some way. This is obviously an area for further study...=

Delivery-date: Thu, 06 Mar 2008 17:37:29 +0000
Date: Thu, 06 Mar 2008 18:37:06 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: [email-masked]
Subject: Re: Rewriting/ingress filtering/NAT/proxy, was: Re: Shim6 Agenda for IETF 71

Hi,

Iljitsch van Beijnum schreef:
> When packets return, routers don't rewrite the destination address. 
> Then, two things can happen: the packets end up at the host itself, 
> which recognizes the rewriting and from then on, sources packets with 
> the source address that was written in the first packet by the router. 
> Or hosts on the subnet are legacy and won't recognize the rewriting, 
> so a middlebox rewrites the destination address to the unique site 
> local prefix. 
This means that it is a requirement to have one of these three options 
(for packet return) :
- All hosts are legacy (and the middlebox always rewrites)
- All hosts recognize the rewriting (and the middlebox never rewrites)
- some hosts are legacy, other not, but the middlebox must be aware of 
the state of each host, so that it can selectively rewrite.

Is it right ?
> The host or middlebox can now start shim6 so that if there is a path 
> failure, the session/context can move to a different address.
Isn't there a possibility that a Shim6 context is established by both 
the middlebox and the host ? Or maybe this can be avoided by 
synchronizing the heuristics for Shim6 negotiation between the host and 
the middlebox  ?

regards,

Sébastien.

Delivery-date: Thu, 06 Mar 2008 17:22:39 +0000
Date: Thu, 06 Mar 2008 18:20:52 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To: [email-masked]
CC: John Ronan <[email-masked]>
Subject: Hosts with multiple interfaces - applicability statement ?

Hi,

Thanks to experiments made by John Ronan, we noticed that a host with 
multiple interfaces was not (always) able to find a working path after a 
failure, even if such a path did exist.

I finally realized that the problem is simply the destination-address 
based routing of the default configurations. With the current stacks (I 
guess this is true for any current operating system), routing is 
completely based on the destination address. We can even have the 
following scenario :
- eth1 has address ADDR_1
- eth2 has address ADDR_2
- The default route is through eth2
- REAP sets the source address of its probe to ADDR_1
- But the packet goes out through eth2 since this is the default route.

The best solution that comes to my mind is to rely on the fact that PA 
addressing requires source address based routing somewhere in the 
network. But if the point where the path can be chosen is in the host 
(through multiple interfaces), then the host must itself perform source 
address based routing.

The solution that worked for the example above and seems clean enough 
was to configure multiple routing tables, one per interface. Then adding 
rules that direct packets with source address ADDR_1 to the table of 
eth1, and so on. An additional default routing table is still necessary 
so that packets with the unspecified source address can still get 
RFC3484 source address selection from the kernel.

Thus there is a solution, but I am afraid that the end user won't 
perform the above configuration, and could complain about misworking 
multihoming functions. Moreover I think that the Shim6 software should 
not make this config on behalf of the user, since this will break in 
case special policy routing configurations are already there.

I think that maybe guidelines for this case should be added to the 
applicability statement draft, so that users are aware of the problem. 
The best would be of course to find something that would be both 
flexible and without configuration from the user. Maybe someone on this 
mailing list has an idea ?

regards,

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

Delivery-date: Wed, 05 Mar 2008 09:05:50 +0000
Cc: shim6 <[email-masked]>, Christian Vogt <[email-masked]>, RJ Atkinson <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Subject: Re: Rewriting/ingress filtering/NAT/proxy, was: Re: Shim6 Agenda for IETF 71
Date: Wed, 5 Mar 2008 10:03:26 +0100

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.

Delivery-date: Wed, 05 Mar 2008 00:00:04 +0000
Date: Wed, 05 Mar 2008 12:57:03 +1300
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>, Christian Vogt <[email-masked]>
Subject: Re: Rewriting/ingress filtering/NAT/proxy, was: Re: Shim6 Agenda for IETF 71

On 2008-03-04 22:29, Iljitsch van Beijnum 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?

> 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?

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.

Back one step:

> 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.

    Brian

Delivery-date: Tue, 04 Mar 2008 09:32:05 +0000
Cc: Christian Vogt <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
To: shim6 <[email-masked]>
Subject: Rewriting/ingress filtering/NAT/proxy, was: Re: Shim6 Agenda for IETF 71 
Date: Tue, 4 Mar 2008 10:29:16 +0100

On 1 mrt 2008, at 11:14, Geoff Huston wrote:

> 6. Next Steps Work Items
>    Iljitsch van Beijnum

>    A discussion on what's missing from the base specification
>    of Shim6 to consider what new work the WG should take on.

Here are some preliminary thoughts on part of this. Please let me know  
what you think so I can grow or shrink this part for next week as  
required...

One of the important things that's still open is the ingress filtering  
situation. The topic of address rewriting in routers in some way also  
resurfaces regularly.

After a discussion with Christian Vogt and some back and forth on the  
IETF list about draft-rosenberg-internet-waist-hourglass-00.txt, I've  
been thinking about NAT in IPv6. The problem with NAT as it's used in  
IPv4 is mainly the port overloading: this breaks incoming traffic.  
Another big problem is the fact that ports and the checksum must be  
rewritten, which means that the NAT must be aware of transport  
protocols. If we get rid of these two issues, NAT almost becomes  
harmless. I'm still not convinced that NAT in IPv6 is a good idea, but  
I AM convinced that if we can limit NAT to strict address translation  
without port overloading that is much, much less harmful than a port  
overloading NAT.

Now combine this with the shim6 proxy, address rewriting and ingress  
filtering stuff and you may end up with something like this:

When an IPv6 host uses unique site locals as source addresses and the  
packets are about to be forwarded to an ISP, the router rewrites the  
top 64 bits of the source address with a prefix that comes from the  
ISP in question. 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.) This means that ingress filtering is no  
longer an issue. Because the checksums for TCP, UDP, ICMP and DCCP  
remain the same, these protocols don't break. RTP doesn't use a  
checksum (although it's generally used on top of UDP so see UDP) and  
unless I'm mistaken. SCTP doesn't include the addresses in its  
checksum , which is a good thing, because it uses a CRC-32 which I  
don't think is incrementally updatable like the normal checksum.

When packets return, routers don't rewrite the destination address.  
Then, two things can happen: the packets end up at the host itself,  
which recognizes the rewriting and from then on, sources packets with  
the source address that was written in the first packet by the router.  
Or hosts on the subnet are legacy and won't recognize the rewriting,  
so a middlebox rewrites the destination address to the unique site  
local prefix. The host or middlebox can now start shim6 so that if  
there is a path failure, the session/context can move to a different  
address.

For packets that aren't the first in a session and that also aren't  
part of a context for which there is shim6 state, the host (or  
middlebox) would fill in the "real" (external) address as a source  
address, which isn't rewritten by routers. Once shim state is  
negotiated, hosts may return to using the unique site local source  
address which can then be rewritten.

This would be a relatively clean type of NAT, the only thing that it  
breaks is referrals. In IPv4 this is often solved by asking a remote  
host to echo back the external address that it sees, but this would be  
problematic if the site is multihomed so the translation would be to  
different addresses based on which ISP is used to reach a particular  
destination...

In the case of a proxy, it would be nice if the proxy could select the  
full 128 bits of the address so it can create an HBA/CGA address, but  
it probably won't be easy to make this checksum-clean.

Delivery-date: Sat, 01 Mar 2008 10:14:52 +0000
Date: Sat, 01 Mar 2008 21:14:08 +1100
From: Geoff Huston <[email-masked]>
To: 'shim6' <[email-masked]>
Cc: Erik Nordmark <[email-masked]>, marcelo bagnulo braun <[email-masked]>, Christian Vogt <[email-masked]>, [email-masked], Iljitsch van Beijnum <[email-masked]>, Kurt Erik Lindqvist <[email-masked]>
Subject: Shim6 Agenda for IETF 71 

Hi,

Here's the agenda for the Shim6 meeting at IETF 71 (Monday afternoon 
session 1 (1300 - 1500)

   Geoff

Shim6 Agenda for IETF 71

1. Summary of current WG Document status
     Kurtis Lindqvist

2. ESD
     Erik Nordmark
     draft-nordmark-shim6-esd

3. Proxy Shim6
     Marcelo Bagnulo
     draft-bagnulo-p-shim6

4. Simplifying Proxy Shim6
     Christian Vogt

5. Path Selection
     Olivier Bonaventure
     draft-bonaventure-informed-path-selection-00.txt

6. Next Steps Work Items
     Iljitsch van Beijnum

     A discussion on what's missing from the base specification
     of Shim6 to consider what new work the WG should take on.

Delivery-date: Sat, 01 Mar 2008 09:34:48 +0000
Date: Sat, 01 Mar 2008 20:32:25 +1100
From: Geoff Huston <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: 'shim6' <[email-masked]>
Subject: Re: Agenda items?

you're on!  thanks

   Geoff

Iljitsch van Beijnum wrote:
> On 27 feb 2008, at 0:20, Geoff Huston wrote:
> 
>> This is a more formal call for agenda items for the next shim6 
>> meeting, as I'm putting together the agenda right now
> 
> I think it would be good if we could have a discussion on what's missing 
> from shim6 the way it is now so that we can decide on what new work to 
> take on. Such as:
> 
> - "initial failures" where the initially chosen address pair doesn't work
> - ingress filtering
> - rewriting addresses in routers
> - proxy shim
>  * with or without NAT
> - traffic engineering
>