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

teardown of the ULID-pair context



Hi,

I have a question about the teardown of the ULID-pair context. In
chapter 9, the proto6 draft says "A reasonable approach would be not to
tear down a context until at least 5 minutes have passed since the last
message was sent or received using the context." Does this include
messages that do not contain a shim6 extension header? My opinion is yes:

If there is a context on host A for host B, this means that both are
multihomed. They should enjoy the goals of multihoming, such as
failover. However, the communication between A and B initially uses the
ULID address pair. Therefore, the IPv6 address fields do not need to be
replaced by a different locator pair, and the message is not tagged with
a shim6 extension header. In other words, the context is not being used
at the moment. This means that if after 5 minutes there was no context
switch, the context states may be teared down again. If shortly after
this the link corresponding to the ULID pair fails, the hosts are not
able to do failover anymore.

So, shim unaware payloads (traffic not using the context) should also be
observed. I suggest that the text 'using the context' in chapter 9 will
be removed.

In order to observer shim unaware payloads, the shim6 layer should look
up a context for these kind of messages. Chapter 11 already defines how
this should be done for sending ULP payloads. For receiving packets
(chapter 12), this information is missing. I suggest there should be a
section before 12.1 receiving payload extension headers:

12.x Receiving payload without extension headers

The receiver extracts the IPv6 source and destination fields, and uses
this to find a ULID-pair context, such that the IPv6 address fields
match the ULID(local) and ULID(peer). If such a context is found, the
context appears not to be quiescent and this should be remembered. The
host continues with proceeding the message.



With regards,

Matthijs Mekking
matthijs@NLnetLabs.nl
NLnetLabs/Radboud University