Subject: mech-v2: unidirectional tunneling removed, SLLA/TLLA changes

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Jan 2004 13:42:04 +0200 (EET)

Hi,

Two status issues on certain mech-v2 features:

1) Based on Chirayu's comments earlier, I've changed the rule (from
SHOULD NOT) to MUST NOT send TLLA/SLLA options on configured tunnels.  
I believe some very old implementations, ages ago, did this, but it
seems to make sense to get them fixed if they want to conform to the
new specification. (See below.)  This does not create a severe interop
problem as long as the other end implements the "MUST ignore" as well.

2) As nobody has offered support for unidirectional tunnels, I removed
them from the mech-v2 revision as well.

If you have any objections, please raise them soon, and provide 
suggested alternatives.

======
   For the purposes of Neighbor Discovery the configured tunnels speci
   fied in this document are assumed to NOT have a link-layer address,
   even though the link-layer (IPv4) does have address.  This means
   that:
                                                                                    
    -   the sender of Neighbor Discovery packets MUST NOT include Source
        Link Layer Address options or Target Link Layer Address options
        on the tunnel link.
                                                                                    
    -   the receiver MUST, while otherwise processing the neighbor dis
        covery packet, silently ignore the content of any Source Link
        Layer Address options or Target Link Layer Address options
        received on the tunnel link.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 28 Jan 2004 14:22:20 +0100

In your previous mail you wrote:

   
=> I object to this change because some usages were found (so could be found
in future) to IPv4 addresses in TLLA/SLLA: "SHOULD NOT" is enough.
An example is the (expired, ask if you can't find it) draft
"draft-ietf-ngtrans-hometun-01.txt" which was implemented and IMHO
has still interested waiting for the MOBIKE stuff which should provide
a better solution.

=> keep previous text and if you'd not like to mix SHOULD and MUST
use the more open one, i.e., SHOULD.

Thanks

[email-masked]

PS: a MUST is incompatible with 6over4 too and we have not free time to
kill (i.e., make historic) 6over4 and all.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 28 Jan 2004 15:32:16 +0200 (EET)

In a slightly different order..

> kill (i.e., make historic) 6over4 and all.

Yes, but that is 6over4, not mech-v2 bis (configured tunneling), so
this seems orthogonal to this argument, specification-wise.

> has still interested waiting for the MOBIKE stuff which should provide

I'm doubtful of the usefulness of preserving something like this, but
unless there are others in the WG who feel that this should be a MUST
NOT and not SHOULD NOT, I can put this back like it was because it
doesn't really cost anything or cause problems.

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