Subject: [16NG] Questions on draft-ietf-16ng-ipv6-over-ipv6cs-02.txt

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 Dec 2006 18:02:18 +0100

Hello to authors of draft-ietf-16ng-ipv6-over-ipv6cs-02.txt.  I am
delving through the document.  I can't review it fully, but may I get
clarification on a few points, thanks.

> 4.1.  IPv6 encapsulation over the IP CS of the MAC
> 
> The IPv6 payload when carried over the IP specfic part of the Packet
>  CS is encapsulated by the 6 byte 802.16 MAC header.

What does the 6-byte 802.16 MAC header look like?  I guess it's
different than a 14-byte Eth MAC header.  It would be very helpful if it
appeared in this draft.

> 6.2.  IPv6 link establishment in 802.16
[...] Steps 1-6 [...]
> The above flow does not show the actual 802.16 messages that are used
>  for ranging, capability exchange or service flow establishment. 
> Details of these are in [802.16e].

I think this section is of paramount importance for understanding how
IPv6 over IPv6 CS works.

However, it does not describe anything meaningful for an implementer.
Is the link establishment happening with IPv6 ppp lcp?

The steps 1-6 describe link-layer messaging, informative, but not in
detail.  It uses terms with ambiguous meanings, such as "REG-REQ (802.16
message)" which can be a Mobile IP message.

If we knew this is ppp, then we could give a more detailed description
with LCP messaging.

If it's not ppp, can we clarify what protocol is, with an RFC number.
PPPoE, L3TP, etc.

> 6.3.  Maximum transmission unit in 802.16
> 
> The MAC HDR is a 6 byte header followed by the payload and a 4 byte 
> CRC which covers the whole PDU.  The length of the PDU is indicated 
> by the Len parameter in the Generic MAC HDR.  The Len parameter has a
>  size of 11 bits.

What's the method to compute the CRC?  Is that a 'trailer' containing
CRC?  IS the CRC a checksum?  Who computes it: the IP stack or the IPv6
CS software.  Is there any pseudo-header involved?

What's the content of the MAC HDR?  Does it contain CIDs?

> 9.1.  Interface Identifier
> 
> The MS has a 48-bit MAC address as specified in 802.16e [802.16e]. 
> This MAC address is used to generate the 64 bit interface identifier
>  which is used by the MS for address autoconfiguration.  The IID is 
> generated by the MS as specified in RFC2464 [RFC2464].

If the MS has a MAC address, is it used in the MAC Header?

Are you sure there is not a big confusion here between IPv6 CS and ETH CS?

Because, if we agree that this is a point-to-point link, then it is very
probable that the ppp protocol is used, and that has a different means
to derive the Interface ID (it's suggested by the AR during
negotiation).  With ppp there's no Interface ID derived from the MAC
address.

Alex

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 13 Dec 2006 11:34:16 -0600

Alex,

Responses inline:

> different than a 14-byte Eth MAC header.  It would be very helpful if it

The 6 byte MAC header is specified in the IEEE 802.16 spec. Take a look at
the Rev-D (or what is called the IEEE 802.16-2004 spec) in section 6.3.2.1.1
It specifies the format of the MAC header and table 5 (below the figure)
explains all the fields of the MAC header. Within the context of this I-D, I
did not believe it is important to explain the details of the 802.16 MAC
header. Suffice it to say it is different from the Ethernet (802.3) header.
For the purpose of IPv6 over the IP cpecific part of the packet CS, it is
not essential to explain the 802.16 MAC header details in this document. The
reference to the IEEE std. 802.16 is sufficient and someone who needs to
understand the format can look up the IEEE spec.

> Is the link establishment happening with IPv6 ppp lcp?

There is no PPP. I do not know how you jumped to a ppp lcp type of
conclusion. Link establishment is handled by the 802.16 layers (PHY/MAC). So
an implementer (of this document which is focusing on the IPv6 layer) would
not need to worry about the link establishment process. The point of this
section is to explain when the MS essentially can send/receive IPv6 packets
including RAs, Router solicitations etc.

> message)" which can be a Mobile IP message.

As I mentioned REG-REQ is an 802.16 specific MAC message. I don't see how
you draw a reference to Mobile IP message here. The text is pretty clear
what this message is. Details of the MAC messages exchanged in establishing
the link are not needed in this document.

> If we knew this is ppp, then we could give a more detailed description

It is not PPP.

> If it's not ppp, can we clarify what protocol is, with an RFC number.

I don't understand what you are trying to say here. The  point is that IPv6
can run directly over the 802.16 MAC (i.e the IP specific part of the packet
CS which is a part of the MAC as I have explained in the document). There is
no PPP or PPPoE type of a layer that IPv6 interacts with.

> CS software.  Is there any pseudo-header involved?

Again if you look at Section 6.3.3.5 of the IEEE Std 802.16-2004 spec you
will see the explanation of the CRC calculation. CRC is a checksum. It is
computed by the MAC layer and not the IP stack. Because as I explained it
includes the MAC header and the IP payload...

> What's the content of the MAC HDR?  Does it contain CIDs?

Yes. Details of the MAC header content as mentioned above in the 802.16
spec.

> If the MS has a MAC address, is it used in the MAC Header?

No.

> Are you sure there is not a big confusion here between IPv6 CS and ETH CS?

Nope. It is pretty clear.

> negotiation).  With ppp there's no Interface ID derived from the MAC

There is NO ppp.. Period.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Dec 2006 11:30:44 +0100

Thanks for responses.

Basavaraj Patil wrote:
>> delving through the document.  I can't review it fully, but may I 
>> get clarification on a few points, thanks.
>> 
>>> The IPv6 payload when carried over the IP specfic part of the 
>>> Packet CS is encapsulated by the 6 byte 802.16 MAC header.
>> different than a 14-byte Eth MAC header.  It would be very helpful
>>  if it appeared in this draft.
> 
> The 6 byte MAC header is specified in the IEEE 802.16 spec. Take a 
> look at the Rev-D (or what is called the IEEE 802.16-2004 spec) in 
> section 6.3.2.1.1 It specifies the format of the MAC header and table
>  5 (below the figure) explains all the fields of the MAC header. 
> Within the context of this I-D, I did not believe it is important to
>  explain the details of the 802.16 MAC header. Suffice it to say it
> is different from the Ethernet (802.3) header. For the purpose of
> IPv6 over the IP cpecific part of the packet CS, it is not essential
> to explain the 802.16 MAC header details in this document. The
> reference to the IEEE std. 802.16 is sufficient and someone who needs
> to understand the format can look up the IEEE spec.

An IPv6 stack can deal with two kinds of links: nd-capable, or not
nd-capable.  When it's nd-capable it needs to build the MAC header, so
its format is very important.  If on the other hand this IPv6 CS is not
nd-capable, then maybe it should be stated so.
>>> The above flow does not show the actual 802.16 messages that are
>>>  used for ranging, capability exchange or service flow 
>>> establishment. Details of these are in [802.16e].
>> I think this section is of paramount importance for understanding 
>> how IPv6 over IPv6 CS works.
>> 
>> However, it does not describe anything meaningful for an 
>> implementer. Is the link establishment happening with IPv6 ppp lcp?
>> 
>> 
>> 
>> 
>> 
> 
> There is no PPP.

Ok, no PPP.  So what is the point-to-point protocol used to establish
the connection?

> I do not know how you jumped to a ppp lcp type of conclusion.

Because it's a point-to-point link.

> Link establishment is handled by the 802.16 layers (PHY/MAC).

Which protocol?  Can I know?  Which tool can I use to see its packets?
Please don't direct me to an IEEE spec.

> So an implementer (of this document which is focusing on the IPv6 
> layer) would not need to worry about the link establishment process.

Not sure about that.  In a point-to-point link link establishment is
very important, because it may negotiate the link-local IPv6 address of
the terminal, which may be different than the MAC address.  And an IPv6
CS which is IPv6-capable will probably do so.

> The point of this section is to explain when the MS essentially can 
> send/receive IPv6 packets including RAs, Router solicitations etc.

Ok.

>> The steps 1-6 describe link-layer messaging, informative, but not 
>> in detail.  It uses terms with ambiguous meanings, such as "REG-REQ
>>  (802.16 message)" which can be a Mobile IP message.
> 
> As I mentioned REG-REQ is an 802.16 specific MAC message. I don't see
>  how you draw a reference to Mobile IP message here.

Because it sounds as Registration Request.  I don't see how you don't se.

> The text is pretty clear what this message is. Details of the MAC 
> messages exchanged in establishing the link are not needed in this 
> document.

Not all of them.  But some.  Those that carry IPv6 addresses for
example, if they do.

>> If we knew this is ppp, then we could give a more detailed 
>> description with LCP messaging.
> 
> It is not PPP.

What is it then?  What is the protocol used to establish the link?

Insisting to say it's not ppp, but not saying what it is shows we don't 
know what is actually.

Why is it _not_ PPP?

>> If it's not ppp, can we clarify what protocol is, with an RFC 
>> number. PPPoE, L3TP, etc.
> 
> I don't understand what you are trying to say here. The  point is 
> that IPv6 can run directly over the 802.16 MAC (i.e the IP specific 
> part of the packet CS which is a part of the MAC as I have explained
>  in the document). There is no PPP or PPPoE type of a layer that IPv6
>  interacts with.

So what's the difference between IPv6 CS and ETH CS?

>>> The MAC HDR is a 6 byte header followed by the payload and a 4 
>>> byte CRC which covers the whole PDU.  The length of the PDU is 
>>> indicated by the Len parameter in the Generic MAC HDR.  The Len 
>>> parameter has a size of 11 bits.
>> What's the method to compute the CRC?  Is that a 'trailer' 
>> containing CRC?  IS the CRC a checksum?  Who computes it: the IP 
>> stack or the IPv6 CS software.  Is there any pseudo-header 
>> involved?
> 
> Again if you look at Section 6.3.3.5 of the IEEE Std 802.16-2004 spec
>  you will see the explanation of the CRC calculation. CRC is a 
> checksum. It is computed by the MAC layer and not the IP stack. 
> Because as I explained it includes the MAC header and the IP 
> payload...

Sorry, too much redirection to the IEEE Std.

> Yes. Details of the MAC header content as mentioned above in the 
> 802.16 spec.
>>> The MS has a 48-bit MAC address as specified in 802.16e 
>>> [802.16e]. This MAC address is used to generate the 64 bit 
>>> interface identifier which is used by the MS for address 
>>> autoconfiguration.  The IID is generated by the MS as specified 
>>> in RFC2464 [RFC2464].

So what does the MS use its MAC address for, other than the IPv6 stack
deriving IIDs.

> Nope. It is pretty clear.

Ok.

>> Because, if we agree that this is a point-to-point link, then it is
>>  very probable that the ppp protocol is used, and that has a 
>> different means to derive the Interface ID (it's suggested by the 
>> AR during negotiation).  With ppp there's no Interface ID derived 
>> from the MAC address.
> 

Ok, I am not that sure, and I will stop disagreeing with you here.

Alex

---

From: "Syam Madanapalli" <[email-masked]>
Date: Thu, 14 Dec 2006 20:10:07 +0530

Hi Alex,

Few comments inline.

> nd-capable, then maybe it should be stated so.

P2P link has only two nodes, so multicast is possible and ND works.
and MAC is not required as long as one can identify the interface on which
the packet has been received. ND is definitely possible over IPv6 CS of 802.16
as long as there exists a P2P link between MS and AR.

> Ok, no PPP.  So what is the point-to-point protocol used to establish

Like Ethernet provides a broadcast medium, 802.16 provides P2P connections.
There is no need to run PPP or other protocols for this.

> Because it's a point-to-point link.

As mentioned above, P2P link is the nature of 802.16 MAC.

> Please don't direct me to an IEEE spec.

802.16 MAC has defined how the connections are established.  Sorry
to say that only IEEE 802.16 specification can provide these details.

> CS which is IPv6-capable will probably do so.

In P2P links, there are two nodes, which still requires DAD between these
two nodes. When using PPP, LCP has been defined to get the IID so that
the DAD can be avoided.

In 802.16 we have a P2P link by default (for IPv6 layer), and we are not using
PPP, LCP, instead we can just use the IID derived from the MAC address and
do DAD between MS and AR.

Thanks,
Syam

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Dec 2006 17:22:19 +0100

Syam Madanapalli wrote:
>>>> Hello to authors of draft-ietf-16ng-ipv6-over-ipv6cs-02.txt.  I
>>>>  am delving through the document.  I can't review it fully, but
>>>>  may I get clarification on a few points, thanks.
>>>> 
>>>>  different than a 14-byte Eth MAC header.  It would be very 
>>>> helpful if it appeared in this draft.
>>> 
>>> The 6 byte MAC header is specified in the IEEE 802.16 spec. Take 
>>> a look at the Rev-D (or what is called the IEEE 802.16-2004 spec)
>>>  in section 6.3.2.1.1 It specifies the format of the MAC header 
>>> and table 5 (below the figure) explains all the fields of the MAC
>>>  header. Within the context of this I-D, I did not believe it is 
>>> important to explain the details of the 802.16 MAC header. 
>>> Suffice it to say it is different from the Ethernet (802.3) 
>>> header. For the purpose of IPv6 over the IP cpecific part of the 
>>> packet CS, it is not essential to explain the 802.16 MAC header 
>>> details in this document. The reference to the IEEE std. 802.16 
>>> is sufficient and someone who needs to understand the format can 
>>> look up the IEEE spec.
>> 
>>  nd-capable.  When it's nd-capable it needs to build the MAC
>> header, so its format is very important.  If on the other hand this
>> IPv6 CS is not nd-capable, then maybe it should be stated so.
> 
> 
> and MAC is not required as long as one can identify the interface on 
> which the packet has been received. ND is definitely possible over 
> IPv6 CS of 802.16 as long as there exists a P2P link between MS and 
> AR.

Is ND possible - probably yes, even though without a MAC header
containing MAC addresses not sure how to implement address resolution.

Is ND necessary on p2p links - probably no, no need of DAD, NUD and
address resolution.  Actually it's not even implemented on existing p2p 
links.

> In 802.16 we have a P2P link by default (for IPv6 layer), and we are 
> not using PPP, LCP, instead we can just use the IID derived from the 
> MAC address and do DAD between MS and AR.

Not sure the necessaity to do DAD between MS and AR.

You say you don't use PPP, LCP.

What do you use such that the mobile learns the address of the AR?  A
mobile with a p2p link absolutely needs to know the address of AR, prior
to RS-RA exchanges.

Alex