Subject: [Mipshop] FMIPv6: About Link-Layer Address Option

From: Nicolas DICHTEL <[email-masked]>
Date: Fri, 04 Aug 2006 16:44:31 +0200

Hello,

about Section 6.4.3. Draft says:

"     Length         The size of this option in 8 octets including the
                     Type, Option-Code, and Length fields.
[snip]
      LLA
           The variable length link-layer address.

      Depending on the size of individual LLA option, appropriate padding
      MUST be used to ensure that the entire option size is a multiple of 8
      octects."

So length must be in 8 octets units.
How the receiver can know where begin the padding ? We only have the option
length, not the LLA length.
If LLA ends with 01, how to know if this value is included in LLA or if it's
a PADN option ?

Regards,
Nicolas

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: <[email-masked]>
Date: Mon, 7 Aug 2006 09:56:12 -0700

>How the receiver can know where begin the padding ? We only 
>have the option length, not the LLA length.
>If LLA ends with 01, how to know if this value is included in 
>LLA or if it's a PADN option ?
>

If Vijay's suggestion in the previous e-mail is acceptable, then it
follows that you derive the padding after the LLA string based on the
alignment requirement for the option that follows it. This makes parsing
a bit messy (you have to go to the next option to determine how much
padding is there after LLA string), but we don't have the length field
for LLA (as you point out). But the implementations can figure it out
based on the wireless technology use, no?

If there is no option following the LLA option, you would have to
"guess"
the LLA length (based on the wireless technology in use). Do we have
better
approaches?

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 07 Aug 2006 10:14:05 -0700

the problem comes from making the option a multiple of
8 octets. I guess this was done to include the option
in a router advertisement. (in RFC 2461 all options
that go into a router advertisement are multiples of
8 octets).

I think we may need a "LLA Length" field in the LLA
option. or remove the 8 octets requirement.

Vijay

---

From: <[email-masked]>
Date: Mon, 7 Aug 2006 10:21:54 -0700

>8 octets. I guess this was done to include the option in a 
>router advertisement. (in RFC 2461 all options that go into a 
>router advertisement are multiples of
>8 octets).

There is LLA, which is carried in PrRtSol and PrRtAdv messages,
and there is MH-LLA. I think we are considering MH-LLA here.

>
>I think we may need a "LLA Length" field in the LLA option. or 
>remove the 8 octets requirement.

For MH-LLA, we can remove the 8 octets, but for any other MH option
we have to decide whether to keep it 8 octets or simply octets.

-Rajeev

>>>      MUST be used to ensure that the entire option size is 
>a multiple 
>>> of 8
>>>      octects."
>>>
>>> If LLA ends with 01, how to know if this value is included 
>in LLA or 
>>> if it's a PADN option ?
>>>
>> 
>> alignment requirement for the option that follows it. This makes 
>> parsing a bit messy (you have to go to the next option to determine 
>> how much padding is there after LLA string), but we don't have the 
>> length field for LLA (as you point out). But the implementations can 
>> figure it out based on the wireless technology use, no?
>> 
>> better approaches?

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 07 Aug 2006 10:30:10 -0700

> and there is MH-LLA. I think we are considering MH-LLA here.

the problem would exist for LLA option also.

> we have to decide whether to keep it 8 octets or simply octets.

only the LLA/MH-LLA have this issue since they have
a field that varies in length.

thinking about this more, adding a "LLA Length" field
is more appealing to me.

Vijay

---

From: <[email-masked]>
Date: Mon, 7 Aug 2006 10:53:57 -0700

>> There is LLA, which is carried in PrRtSol and PrRtAdv messages, and 
>> there is MH-LLA. I think we are considering MH-LLA here.
>

Actually, LLA processing is the same as in 2461 (sec 4.6.1). There is no
length field there. I think they determine it based on the ETHER_TYPE
(see
the description of LLA option in 4.6.1 in 2461). 

So, I am wondering whether to specify the LLA length field or let folks
determine it based on the particular link-type..

>
>only the LLA/MH-LLA have this issue since they have a field 
>that varies in length.

right, so we have a consistency issue.

>
>thinking about this more, adding a "LLA Length" field is more 
>appealing to me.

should we specify it or leave it to implementers to determine?

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 07 Aug 2006 11:02:06 -0700

> should we specify it or leave it to implementers to determine?

I would prefer adding the LLA Length field.

Vijay

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 07 Aug 2006 14:40:14 -0400

Hi Rajeev,
   Please see comments inline.

Cheers
Suresh

> the description of LLA option in 4.6.1 in 2461). 

RFC2461 leaves the LLA length unspecified, but LLA length is not 
directly determined by the ether type. It needs to be defined by the 
"IPv6 over foo" document for the specific media type. For ethernet this 
is done in section 6 of RFC2464.

> should we specify it or leave it to implementers to determine?

I think Vijay's idea about adding a LLA length looks good, but it is not 
really mandatory to add. Since the IPv6 (over foo) implementation knows 
about the media type it can figure out the LLA length equally well.

>> Vijay
<snip>

---

From: Nicolas DICHTEL <[email-masked]>
Date: Tue, 08 Aug 2006 10:43:00 +0200

Vijay Devarapalli a écrit :
>>> 8 octets. I guess this was done to include the option in a router 
>>> advertisement. (in RFC 2461 all options that go into a router 
>>> advertisement are multiples of
>>> 8 octets).
>>
The problem exists only for LLA. The length for MH-LLA is in units of 
octects (Section 6.4).

Regards,
Nicolas