[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LIN6 i-d for multihoming and mobility support
Hi Brian,
At 04/01/12 15:49 +0100, Brian E Carpenter wrote:
>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?
We assume that EUI-64 is used as the LIN6 ID (64 bits). By definition,
each EUI-64 number is globally unique. LIN6 IDs can be assigned in a
hierarchical manner like IPv6 address assignment. Or computer vendors can
assign a LIN6 ID to their computer like Ethernet MAC address.
>> 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?
The same problem in IP-in-IP tunneling in MIPv6 arises. That is, if
non-LIN6 node sends a MTU-size packet, it is fragmented at MA before
MA forwards it.
>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?
Each network can have a distinct MA. Packet forwarding does not
concentrate at 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?
This is a mistake. We will fix it in the next version.
>> 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?
Currently, only one EUI-64 is used for our test operation of LIN6.
Multiple EUI-64 numbers can be used as LIN6 ID. Basically, 62 bits can be
used as LIN6 ID (2 bits in EUI-64 have special meanings.)
>> 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?
In our design principle, the network layer should obey the policy of
upper layers. In other words, the source and the destination locator should
be selected in the transport layer or the application layer.
Fumio Teraoka
> 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