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

Re: LIN6 i-d for multihoming and mobility support



Hi, I have a few questions about LIN6

>       LIN6 ID:
>          The LIN6 ID is assigned to the node and uniquely identifies the
>          node in the Internet.  It is 64 bits in length.

How is this unique number assigned and how is it guaranteed unique?

>          the distinct MA.  The MA also has packet forwarding function.  If
>          a non-LIN6 node sends a packet to a LIN6 node, the packet reaches
>          the MA of the LIN6 node first because the AAAA record of the LIN6
>          node specifies the network prefix of the MA of the LIN6 node.
>          When the MA receives such a packet, the MA forward the packet to
>          the LIN6 node by IP-in-IP tunneling.

What is the impact of this on MTU size issues?

How does this scale? For example, if half the network is on LIN6 and
the other half on normal IPv6, doesn't this means that about 50% of all
packets will be forced through an MA?

> 
>    aggregatable   +--+------+---+------+------+--------------------------+
>    global unicast |FP|TLA ID|res|NLA ID|SLA ID|     Interface ID         |
>    address        +--+------+---+------+------+--------------------------+
> 
>             Figure 1: The LIN6 generalized ID and the LIN6 address

The FP/TLA/MLA structure is obsolete. Why mention it?


> 3.3.  Distinction between the LIN6 Address and the Normal IPv6 Address
> 
>    As shown on the right side of Figure 2, the receiving node must
>    distinguish the LIN6 address from the normal IPv6 address to decide
>    whether address conversion must be done.  From address format viewpoint,
>    however, the LIN6 address is indistinguishable from the normal IPv6
>    address, i.e., LIN6 is fully compatible with IPv6.  There are some
>    methods to distinguish the two address types.  As a temporary solution,
>    LIN6 employs a special value as a part of the LIN6 ID.  To distinguish
>    the LIN6 address, Keio University obtained the OUI value 0x00-0C-21 of
>    EUI-64[EUI64].  According to the IPv6 addressing scheme, the
>    Universal/Local bit of EUI-64 must be reversed in the global IPv6
>    address.  Thus, if the upper 24 bits of the lower 64 bits of the IPv6
>    address is 0x02-0C-21, the IPv6 address is the LIN6 address.

This only allows 40 variable bits - and 2**40 is not really enough for
IPng's goals. So what is the permanent solution?

> 3.9.  Multihoming Support
...
>    When Node-A sends a LIN6 packet to Node-B, the transport layer of Node-A
>    can choose the source and the destination network prefixes by indicating
>    them explicitly to the network layer.  Upon receiving a LIN6 packet on
>    Node-B, the network layer passes the source and the destination prefixes
>    to the transport layer in addition to the source and the destination
>    LIN6 generalized IDs.  Thus, the transport layer of Node-B can know the
>    source and the destination network prefixes of the received packet.

It's unclear to me why this has to happen in the transport layer. Why can't
it happen inside the socket at network layer?

    Brian

Fumio Teraoka wrote:
> 
> Hi all,
> 
> I have just submitted draft-teraoka-multi6-lin6-00.txt that describes
> multihoming and mobility support based on LIN6. Sec.8 discusses
> the features of LIN6 based on RFC3582.
> 
> The draft is available from the following URL:
> 
> http://www.tera.ics.keio.ac.jp/person/tera/multi6/draft-teraoka-multi6-lin6-00.txt
> 
> Comments are welcome.
> 
> Fumio Teraoka