Re: [MEXT] GRE support in DSMIPv6 - AD review

[<[e-mail]>]

Henrik Levkowetz wrote:

> That would work for me.  I'd very much like to see the TLV header
> itself kept; the reason is that if something else (GRE or whatever)
> than an IP header follows the UDP header, there isn't a clear and
> obvious way of dynamically distinguishing *what* that something else
> is, unless the TLV header is there.  Ripping it out completely would
> leave the specification less ready for extension than otherwise,
> which would be unfortunate if we already know that there are needs
> for extension.

Right.. however, since the future extensions will include a
negotiation mechanism (some bit somewhere) to say "I support this
extension FOOBAR (which implies using TLV header)", do we need 
a separate "I support TLV header" bit in this spec?

(Since if you don't support any of the extensions, sending normal
IPv4/IPv6 using the TLV format seems a bit strange.)

BTW -- currently, the spec says that the packet has a *single* TLV
header (not a sequence of them), so the length field isn't
actually used for anything -- so it's really TV header :)

> One thing in the -05 and -06 drafts which surprised me when looking
> at them now was the value assignments for the TLV type field -- I'd
> expected the use of already-defined protocol numbers here, in a
> similar manner to what's in Section 3.3 of RFC 3519, rather than a
> new registry.  But there are maybe things I've forgotten from our
> earlier discussion which makes a new type number space necessary.

Even when TLV header is negotiated, some packets (at least BUs) are
sent without the TLV header (the IP header starts immediately after
UDP header).

Currently, the TLV Type field is just 4 bits (to align it with the IP
version number field), and obviously values 4 and 6 won't work
(for some reason, the current spec also forbids values 2, 3, 5,
and 7..15 -- I can't see why that couldn't be relaxed...).

If it was 8 bits, at least TLV types 0x40..0x4f and 0x60..0x6f would 
need to be reserved (and that would complicate using already-defined 
protocol numbers).

Best regards,
Pasi
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext