Subject: [16NG] comments on draft-riegel-16ng-ip-over-eth-over-80216-01.txt

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Dec 2006 18:29:30 +0100

Hello to authors of draft-riegel-16ng-ip-over-eth-over-80216-01.txt.
Thanks for this draft, I have some comments.

Abstract:
> This document describes the behavior of the Ethernet emulation on top
>  of IEEE 802.16 to efficiently support the transmission of IPv4 as 
> well as IPv6 packets over IEEE 802.16 radio links.

I don't think it is necessary for IETF to describe the behaviour of
Ethernet emulation.  It should describe what Ethernet 'interface' to
present to the IP stack: MTU, multicast, link-local addressing.

In light of this, I think section 8 'Transmission of IP over Ethernet'
of this draft is very relevant.  All the other sections - while relevant
and educative - should be pursued as INFORMATIONAL.  I can remark
separately on sections 5-6-7, if needed.

> 8.2.  IPv6 over Ethernet

This is a good section.  It lacks the req of MTU 1280.  A statement
could be: "ETH CS ensures that IPv6 packets delivered to it of size 1280
bytes will not be reported back to the stack as 'packet too big'".

It should state that an IPv6 link-local address is derived  by adding
the fe80 to the interface id which itself is derived from ETH CS's 48bit
MAC address.  With a reference to RFC2464 (IPv6 over Ethernet).

It could detail that the ethertype over ETH CS is what it is.  Again
followed by the RFC reference.

> This document assumes a point-to-point connection between each SS and
>  bridge.  The ND Relay Agent of the bridge unicast the RA from AR via
>  the point-to-point connection.

With all the draft's discussion about ND Relay Agent, I'm torn between
deciding whether ND Relay Agent is - or is not - an IETF matter.  I
think that _if_ ND Relay Agent becomes an IETF matter, it should be out
of this document, and should complement at least two other RFCs: 3775
(Mobile IPv6 - Proxy ND) and 246x (Neighbour Discovery).

I think ND Relay Agent behaviour/spec should be outside the document
"IPv6 over 802.16 ETH CS".

But it does make sense to talk about the underlying link being point to
point and the ETH CS 'interface' to IPv6 stack to be ND-capable.  This
is a 802.16 particularity.

8.2.2.1.  Stateful Address Autoconfiguration:
> When the'M' flag in the received RA is set, a SS should perform 
> stateful address configuration according to [RFC3315].  In this case,
>  an AR supports DHCPv6 server or relay function.

This is not clear.  Is it that the SS is the DHCP Client?  Or is it  the
eventual hosts behind the SS?

Remark RFC2464 "IPv6 over Ethernet" doesn't talk at all about stateful
autoconfig.

> 8.2.3.  Address Resolution
> 
> The Source Node sends Neighbor Solicitation to the solicited-node 
> address corresponding to the target address for address resolution.

'Solicited-node address'?  Prior the draft talks about 'solicited node
MAC address'.  Not sure what those two are.  There is a solicited node
multicast address derived from the last 24 bits of the IP address and
appended ff02-something to it.  RFC4291 IPv6 Addressing Architecture.

> Upon receiving the Neighbor Solicitation, the bridge retrieves the 
> port corresponding to the solicited-node MAC address in its ICT and 
> then forwards the Neighbor Solicitation via that port.

Not sure we need to specify the bridge behaviour here.

> Finally the Target Node responds to the Neighbor Solicitation.

This is strange.  A node usually sends this NS to solicited-node
multicast address as part of DAD and the Target node usually doesn't
respond - hopefully.

> 8.3.  Maximum Transmission Unit Consideration
> 
> When stacked VLAN headers are transferred over GRE tunnels, the sizes
>  of the VLAN headers and the GRE header need to be considered in 
> setting the value of MTU of the transport path.

Surely the document has to talk about MTU.  But first the specific
cases, i.e. 1280 bytes, as per RFC2464 IPv6 over Eth.  And only then
about what can happen if VLAN or GRE is used.  These two latter cases
may be too complicated.

> 9.  Security Considerations
> 
> [RFC3971] specifies security mechanisms for ND Protocol and defines 
> means for securing ND Protocol messages.  This document aims to fully
>  support security mechanisms specified in [RFC3971].

On a side note.  ND Relay and SeND: not sure how that works, because not
sure what ND Relay is.  SeND extensions may look at what to do about
proxy ND, but not Relay ND.

But this again can be part of other document.  This document can simply
say what are the risks of using IPv6 over ETH-CS as opposed to using
IPv6 over Ethernet.  There may be no differences in risks.

Alex

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

---

From: "NCUCE-ywchen" <[email-masked]>
Date: Wed, 13 Dec 2006 09:54:09 +0800

Hi,

I am Yen-Wen Chen, National Central University, Taiwan, my lab has worked on 
FMIPv6 over 802.16 for a long time and we have some idea on this issue. 
Could someone send me a full set of this draft??
Many thanks!

Sincerely,
Yen-Wen Chen

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 13, 2006 1:29 AM
Subject: [16NG] comments on draft-riegel-16ng-ip-over-eth-over-80216-01.txt

>>  of IEEE 802.16 to efficiently support the transmission of IPv4 as well 
>> as IPv6 packets over IEEE 802.16 radio links.
>
>> When the'M' flag in the received RA is set, a SS should perform stateful 
>> address configuration according to [RFC3315].  In this case,
>> The Source Node sends Neighbor Solicitation to the solicited-node address 
>> corresponding to the target address for address resolution.
>
>> Upon receiving the Neighbor Solicitation, the bridge retrieves the port 
>> corresponding to the solicited-node MAC address in its ICT and then 
>> forwards the Neighbor Solicitation via that port.
>
>>  of the VLAN headers and the GRE header need to be considered in setting 
>> the value of MTU of the transport path.
>
>> [RFC3971] specifies security mechanisms for ND Protocol and defines means 
>> for securing ND Protocol messages.  This document aims to fully

---

From: "Ray Bell" <[email-masked]>
Date: Tue, 12 Dec 2006 19:53:18 -0800

Yen-Wen,

I'm not involved with this, but you can find the draft at:

http://tools.ietf.org/wg/16ng/draft-riegel-16ng-ip-over-eth-over-80216-01.tx
t

-----Original Message-----
From: NCUCE-ywchen [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2006 5:54 PM
To: Alexandru Petrescu; [email-masked]
Subject: Re: [16NG] comments on
draft-riegel-16ng-ip-over-eth-over-80216-01.txt

Hi,

Sincerely,
Yen-Wen Chen

---

From: Daniel Park <[email-masked]>
Date: Wed, 13 Dec 2006 14:17:39 +0900

Yen-Wen, 

Here is a relevant publication:
http://www.watersprings.org/pub/id/draft-ietf-mipshop-fh80216e-00.txt

I guess you are saying the exact same subject.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.