Re: [ipwave] I-D Action: draft-ietf-ipwave-ipv6-over-80211ocb-01.txt - empty section "Address Mapping -- Unicast"

[Alexandre Petrescu <[e-mail]>]

Michelle,

You are pointing that the section 5.4 "Address Mapping -- Unicast" 
section is empty.

I will explain why.

This section is one of the most difficult sections to write.

The original intention was that be precisely the same as section 6 
"Address Mapping -- Unicast" of RFC2464.

But process: IETF 6MAN WG committed on a path of updating the status of 
'core' IPv6 specs, including RFC 2464.  A promising document in that 
direction is draft-hinden-6man-rfc2464bis-01. This document is an 
individual proposal at this time.  Maybe soon there will be a call for 
adoption as WG item.  Until that's done, it's hard to say whether it's 
legitimate or not to copy something from it.

The text in question, that should come into our draft, in section 
"Address Mapping -- Unicast", is the following:
>    The procedure for mapping IPv6 unicast addresses into Ethernet link-
>    layer addresses is described in [DISC].  The Source/Target Link-layer
>    Address option has the following form when the link layer is
>    Ethernet.
>
>                     0                   1
>                     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |     Type      |    Length     |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                    |                               |
>                    +-          Ethernet           -+
>                    |                               |
>                    +-           Address           -+
>                    |                               |
>                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>    Option fields:
>
>    Type                1 for Source Link-layer address.
>                        2 for Target Link-layer address.
>
>    Length              1 (in units of 8 octets).
>
>    Ethernet Address    The 48 bit Ethernet IEEE 802 address, in
>                        canonical bit order.  This is the address the
>                        interface currently responds to, and may be
>                        different from the built-in address used to
>                        derive the Interface Identifier.


You will notice that text has a number of issues, that I list here for 
information:

- the [DISC] reference is RFC4861.  That text uses terms 'mapping' and 
'resolving' alternatively.  Whereas here we only say 'mapping'. 
'Mapping' is ambiguous in that it some times involve a message exchange 
like ND, other times not like when following a pre-written rule.  I 
would prefer to use 'resolve'.  But will that make it different from 
RFC2464?  Too big difference?

- the text seems to recommend to have a direct relationship between an 
Ethernet Address and an IP address.  This is an old formulation that 
IETF is trying to move away from; many RFCs were issued recently about 
these Interface IDs ensuring privacy.

Overall, this text deserves much clarification that I am not able to 
propose right now.

This should be further discussed before having text there.

What do you think?

What do WG members think?

Alex