Comments on draft-bagnulo-shim6-addr-selection-00.txt
Jari Arkko <jari.arkko@piuha.net> Wed, 05 October 2005 06:44 UTC
Envelope-to: shim6-data@psg.com
Delivery-date: Wed, 05 Oct 2005 06:44:45 +0000
Message-ID: <43437640.5030501@piuha.net>
Date: Wed, 05 Oct 2005 09:44:16 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
CC: shim6-wg <shim6@psg.com>
Subject: Comments on draft-bagnulo-shim6-addr-selection-00.txt
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Hi Marcelo, And thanks for writing this draft. This is an important scenario to cover. Generally speaking I like your solutions. A few comments, however: >5.1.1. Direct link failures > The title seems a bit misleading. I thought first that you were talking about the direct link from the host, but this was really the link from the local router to the ISP. Anyway, I think you are missing a discussion of the first case. Here it may even be that existing mechanisms already solve the problem, because presumably RFC 3484 would not select source addresses from a link that's down. But it would still be important to note this. > The missing part is a mechanism to convey the information from the > server to the host. A possible option is to define a new DHCP option > to transmit policy table information. > > This does not appear to be able to deal with dynamic outages, or does it? At the very least the lease times would have to be set low. > It is also possible to enable the multihomed host to query the server > to obtain the source address prefix information as proposed in [6] . > In this case, each time the multihomed node initiates a communication > with a new destiantion, it would query the server for the proper > prefix to include in the source address. The server, would reply > based on the routing information it has gathered through BGP. > > This might be a better alternative, perhaps modified by only doing the query if you can't establish a connection. > The first option is to simply let the upper layers to handle > retrials. In this case, the IP layer only has to make sure that a > different source address is used in each retrial as long as there is > not a preferred source address in the source address cache. So, in > this approach, when the IP layer receives a packet, it searches the > Source Address Cache for a preferred source address associated to the > selected destination. If no entry exists for that destination > address, one of the available source addresses is selected randomly. > If reply packets arrive, an entry will be created in the Source > Address Cache for that destination address. If no reply packets > arrive, no entry will be created, so when the upper layer protocol > resends the packet, a new source address will be used. > > I may be confused here, but I suppose you are not talking about IP packets, you are talking about connection initiation. You can't change source address on the fly from an existing TCP sessions. --Jari
- Re: Comments on draft-bagnulo-shim6-addr-selectio… Jari Arkko
- Re: Comments on draft-bagnulo-shim6-addr-selectio… marcelo bagnulo braun
- Comments on draft-bagnulo-shim6-addr-selection-00… Jari Arkko