Subject: [16NG] AD review of draft-ietf-16ng-ipv6-over-ipv6cs

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Dec 2006 21:02:53 +0200

Hi,

I reviewed the new version of this specification.
Overall, it has no major technical problems but
still needs another editing round to tighten
the language, move non-core descriptive text to
an appendix, correct a few mistakes, and explain
how IPCS/Eth/Etc will be interoperable in a
multi-vendor environment that is not completely
under the control of a single administration.

Please see the comments below:

>    The scope of this document is limited to IPv6 operation over the IP
>    specific part of the Packet CS only.  It should be noted that while
>    capability exchange of the MS and BS is performed, there is no
>    negotiation of which service specific part of the packet CS will be
>    used for IPv6 transport.
This is still problematic.

I would not keep on raising this if I thought the current
text would pass the final IESG review, but given the attention
to this issue in the chartering stage you HAVE to provide
a credible explanation of how this does not end up
in interoperability problems.

>                        Figure 3: IPv6 encapsulation
This is vague. I know it was me who asked for the
picture, but this picture is not helpful in terms
of me actually knowing how to implement anything.
Perhaps you should just keep the first sentence
of Section 4.1, and add references to the specific
IEEE documents and their sections.
> 5.1.  WiMAX network architecture and IPv6 support
> 6.1.1.  IPv6 link in WiMAX
> 6.2.1.  IPv6 link establishment in WiMAX
> 6.3.1.  Maximum transmission unit in WiMAX

I would like to move the WIMAX sections to an
appendix. I do not see anything in them that
requires the implementor to know about it,
as long as we are talking about the "IPv6
over 802.16" part. And this spec is the
better the shorter it is. And there will
be less questions from the reviewers
and the rest of the IESG.

You can add a forward reference 
to the appendix in their place,
however. For instance, "Further details
relating to the network setup / tunnel set
up / MTU in WIMAX networks are described
in Appendix X."

>    The collection of service flows (tunnels) to an MS is defined as a
>    single link.  Each link has only an MS and an AR.  Each MS belongs to
>    a different link.  No two MSs belong to the same link.  A different
>    prefix should be assigned to each unique link.  This link is fully
>    consistent with a standard IP link, without exception and conforms
>    with the definition of a point-to-point link in RFC2461 [RFC2461].
This part of 6.1.1 should probably be listed
in Section 6.1 already, because it appears
to be universally true.
> The prefixes
>    are advertised with the on-link (L-bit) flag set to facilitate
>    Detecting Network Attachment (DNA) operation [RFC4135].
You are referring to a goals document and there is
no published protocol to go with it.

But there are other reasons why setting the L bit
makes sense. In general, this specification mixes
operational advice with implementation requirement,
and it is very unclear whether, for instance,
if L=0 would be disallowed in 802.16.

I would suggest making it clear which parts of
the document actually state something that is
mandatory and what is not. For instance, this
section could be rewritten as follows:

   Each MS MUST be considered to be on a separate subnet as 
   a result of the point-to-point connection.

   The size and number of the prefixes is a configuration
   issue. Also, prefix delegation may be used to provide
   additional prefixes for a router connected over 802.16.

   The other properties of the prefixes are also a
   configuration issue. But typically the prefixes
   are advertised with the on-link (L-bit) flag set.

>    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].  For addresses
>    that are based on privacy extensions, the MS may generate random IIDs
>    as specified in RFC3041 [RFC3041].
IID is an undefined abbreviation in this document.
Also, again, its hard to determine what the document is
really mandating in terms of EUI-64 usage.

How about this: "The MS has a 48-bit MAC address as specified in
802.16e [802.16e]. This MAC address can be used if EUI-64 -based
interface identifier is needed for autoconfiguration [RFC 4291].
As in other links that support IPv6, EUI-64 -based interface
identifiers are not mandatory and other mechanisms, such as
random interface identifiers [RFC 3041] may also be used."

>    If the A-bit in the prefix information option (PIO) is set, the MS
>    performs stateless address autoconfiguration as per RFC 2461, 2462.
>    The AR is the default router that advertises a unique /64 prefix (or
>    prefixes) that is used by the MS to configure an address.
The second sentence seems to imply that the prefix
size has to be exactly 64 bits. You could fix that
but I'm not sure the second sentence is actually
adding anything useful here. You already stated
earlier that the prefixes are per-MN.

>    This document does not introduce any new vulnerabilities to IPv6
>    specifications or operation as a result of the 802.16 air interface
>    or the WiMAX network architecture.
I do not think you want to claim that there are no
new vulnerabilities because of the 802.16 link.
How about this:

  This document does not introduce any new vulnerabilities to IPv6
  specifications or operation. The security of the 802.16 air
  interface is the subject of [REFERENCE]. In addition, the
  security issues of the network architecture spanning beyond
  the 802.16 base stations is the subject of the documents
  defining such architectures, such as [REFERENCE].

>    [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
>               Stateless Address Autoconfiguration in IPv6", RFC 3041,
>               January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>.
Please refer to draft-ietf-ipv6-privacy-addrs-v2-05, because
it is in the RFC Editor's queue already.
>    [RFC3314]  Wasserman, Ed., M., "Recommendations for IPv6 in Third
>               Generation Partnership Project (3GPP) Standards",
>               RFC 3314, September 2002,
>               <ftp://ftp.isi.edu/in-notes/rfc3314>.
>    [RFC3756]  Nikander, P., Kempf, J., and E.  Nordmark, "IPv6 Neighbor
>               Discovery (ND) Trust Models and Threats", RFC 3756,
>               May 2004, <ftp://ftp.isi.edu/in-notes/rfc3756 >.
>
>    [RFC4135]  Choi, JH. and G. Daley, "Goals of Detecting Network
>               Attachment in IPv6", RFC 4135, August 2005,
>               <ftp://ftp.isi.edu/in-notes/rfc4135>.
These should be informational references. Nothing
in those document is needed to implement this.

>    The addressing scheme for IPv6 hosts in 802.16 network follows the
>    IETFs recommendation for hosts specified in RFC 4294.  The IPv6 node
>    requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are
>    applicable for addressing.
> ... 
>    [RFC4294]  Loughney, Ed., J., "IPv6 Node requirements", RFC 4294,
>               April 2006, <ftp://ftp.isi.edu/in-notes/rfc4294>.
Not sure what "recommendation" exists in 4294 -- it simply points
to existing RFCs on, say, addressing. Perhaps you meant RFC 3314
in the first sentence? By the way it isn't mentioned in the text.
> TBD.

I realize this in an acks section, but the document
needs to be complete when its shipped to the IESG.
You cannot edit it afterwards.

>    o  delivering the CS PDU to theappropriate service flow and transport
s/thea/the a/

--Jari

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

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 14 Dec 2006 11:28:00 -0600

Jari,

Let me see if I can explain this better below and address the concerns
about interoperability. A bit of a long explanation. But given the
importance of this issue, I would prefer that we are on the same page
and in sync.

>in interoperability problems.

Support for IP (v4/v6) is provided by the packet CS. The IP specific
part of the packet CS supports both IPv4 and IPv6. The 802.3
(Ethernet) specific part and 802.1Q (VLAN) specific parts of the
packet CS can also be used as the lower layers for IP(v4/v6). The
question is how does the IPv6 layer in a host determine which specific
lower layer to use.
In the case of IPv6 over 802.3, the IPv6 stack interacts with the
Ethernet driver or interface. It is this Ethernet driver or interface
that then interfaces with the 802.16 packet CS. The packet CS uses
classifiers to determine how the packets from the upper layer are
processed. So if the packet CS essentially receives an Ethernet frame
(which includes the IPv6 payload), the packet CS classifiers will
process it based on the Ethernet header. The fact that the packet
includes an Ethernet header will cause the Ethernet specific part of
the packet CS to process this packet. The IEEE 802.16 std does say
that
"For IP over IEEE 802.3/Ethernet, IP headers may be included in
classification." 
Note the May aspect of the above statement.
The classifiers for 802.3 are : destination MAC address, source MAC
address, Ethertype/SAP.
Hence if IPv6 is transmitted via the Ethernet interface, the
classifiers in the packet CS will ensure that the packet is mapped to
a transport connection that has been established for it specifically
and the BS will have the corresponding processing and forward it via
an appropriate connection via the uplink.
The same applies in the case of IPv6 over 802.1Q as well.

Now in the case IPv6 interfaces directly with the 802.16 MAC (Packet
CS), the IPv6 stack delivers the IPv6 packet to the packet CS. The
classifiers in the packet CS will determine that this packet is to be
handled by the IP specific part of the packet CS. The IP classifiers
defined by the 802.16 spec are:
- IP type of service/DSCP [IETF RFC 2474]
- The IP Protocol field.  For IPv6  (IETF RFC 2460), this refers to
  next header entry in the last header of the IP header chain.
- a list of IP source addresses (designated ³srci²) and their
  corresponding address masks (designated ³smask²). If this parameter
  is omitted, then comparison of the IP packet source address for this
  entry is irrelevant.
- a list of IP destination addresses (designated ³dsti²) and their
  corresponding  address masks (designated ³dmaski²). If this
  parameter is omitted, then comparison of the IP packet destination
  address for this entry is irrelevant.
- Protocol source port range. If this parameter is omitted, the
  protocol source port is irrelevant. This parameter is irrelevant for
  protocols without port numbers.
- Protocol destination port range. If this parameter is omitted, the
  protocol destination port is irrelevant. This parameter is irrelevant for
  protocols without port numbers.

So based on these classifiers the IP specific part of the packet CS
interacts with the Common Part sublayer of the MAC to determine which
transport connection (CID) to use to transmit the packet. On the BS
side, the same corresponding process occurs and as a result is able to
send the packet via an appropriate uplink transport.

A transport connection between an MS and BS is established by sending
a DSA-REQ (802.16 MAC) message. One of the TLVs in the DSA-REQ message
is called "CS Specification. This parameter specifies the CS that the
connection being set up shall use.
The values in this TLV are:
0: No CS 
1: Packet, IPv4 
2: Packet, IPv6 
3: Packet, 802.3/Ethernet
4: Packet, 802.1Q VLAN
5: Packet, IPv4 over 802.3/Ethernet
6: Packet, IPv6 over 802.3/Ethernet
7: Packet, IPv4 over 802.1Q VLAN
8: Packet, IPv6 over 802.1Q VLAN
9: ATM 
10-255 Reserved 

So as a result of the DSA-REQ/RSP a transport connection is setup
which has a CS specific binding to it.

Hopefully this gives some background on how the Packet CS of the
802.16 MAC handles upper layer packets. So negotiation about which
specific CS to use for a specific transport connection (an MS-BS pair
can have multiple transport connections) is handled by the MAC layer
when the transport connection is established.

So I do not see an issue w.r.t interoperability. When you say
interoperability, I was wondering what specifically were you concerned
about.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Dec 2006 20:15:42 +0100

Raj, please allow me to interfere,

Basavaraj Patil wrote:
> Jari,
> 
> Let me see if I can explain this better below and address the 
> concerns about interoperability. A bit of a long explanation. But 
> given the importance of this issue, I would prefer that we are on the
>  same page and in sync.
> 
> 
>>> The scope of this document is limited to IPv6 operation over the 
>>> IP specific part of the Packet CS only.  It should be noted that 
>>> while capability exchange of the MS and BS is performed, there is
>>> no negotiation of which service specific part of the packet CS 
>>> will be used for IPv6 transport.
>> I would not keep on raising this if I thought the current text 
>> would pass the final IESG review, but given the attention to this 
>> issue in the chartering stage you HAVE to provide a credible 
>> explanation of how this does not end up in interoperability 
>> problems.
> 
> packet CS can also be used as the lower layers for IP(v4/v6).

Ok.

> The question is how does the IPv6 layer in a host determine which 
> specific lower layer to use.

Yes, good question.  Traditionally the IPv6 layer doesn't care much
about the sub-layers behind a  MAC layer.  Its choices are how to choose
between interfaces, and that's based on nd and rt tables.  If there's a
WiFi interface, and a 802.16 ETH CS in the system, the IP stack chooses
among them based on rt and nd tables.

What the IP stack needs to know is whether it performs nd over a
particular interface or not.

>  the packet CS to process this packet.

Ok, I understand that's ETH CS.

> The IEEE 802.16 std does say that "For IP over IEEE 802.3/Ethernet, 
> IP headers may be included in classification."

I guess that's  only for the goal of header suppression, and there are
IETF ways to achieve that, for p2p links included (PPP compression,
ROHC, etc).

> Note the May aspect of the above statement.

Of course it's a May.  If the IPv6 headers contain encrpyted port
numbers I'm not sure how the CS can read that.  I don't think CS
implements IPsec.

> The classifiers for 802.3 are : destination MAC address, source MAC 

Ok.  This is related to IPv6 over ETH CS: do you think the classifier
expects 0x86DD in the Ethertype field of a IPv6 packet sent over ETH CS?
  This is very good to know for the IPv6 over ETH CS document.

>  an appropriate connection via the uplink. The same applies in the 
> case of IPv6 over 802.1Q as well.

Ok.

>  CS), the IPv6 stack delivers the IPv6 packet to the packet CS.

Ok, with no intermediary header?  This is good to know.

I think I understand that _if_ CS is IPv6 CS then the link presented to
the stack is a point-to-point link (_like_ ppp would do).

> The classifiers in the packet CS will determine that this packet is 
> to be handled by the IP specific part of the packet CS. The IP 
> classifiers defined by the 802.16 spec are: - IP type of service/DSCP
>  [IETF RFC 2474]

Shorter term in IPv6 is "Traffic Class" field.

> next header entry in the last header of the IP header chain.

Some if not all 'last' headers just don't have a next header field.
It's the case for ICMPv6, TCP, UDP and ESP.

There's no such thing as "IP header chain".  There's a base header, some
extension headers and some payload.  Their definition is very fuzzy,
interpretation depends on context.

MH header's Payload Proto field is "IPPROTO_NONE". MH doesn't have a
"Next Header" field.

Strange enough, I thought they need the "IP version number field" in
order to distinguish between IPv4 and IPv6.  It doesn't appear in the list.

> corresponding address masks (designated ³smask²).

There's nothing in the IPv6 packet that says what prefix that
src address has.  Not sure what the 'smask' is useful for in the classifier.

And, it's no longer called 'mask' in IPv6, it's 'prefix length'.

> If this parameter is omitted, then comparison of the IP packet source
>  address for this entry is irrelevant. - a list of IP destination 
> addresses (designated ³dsti²) and their corresponding  address masks 
> (designated ³dmaski²).
> 
> If this parameter is omitted, then comparison of the IP packet 
> destination address for this entry is irrelevant. - Protocol source 
> port range. If this parameter is omitted, the protocol source port is
>  irrelevant. This parameter is irrelevant for protocols without port
>  numbers. - Protocol destination port range. If this parameter is 
> omitted, the protocol destination port is irrelevant. This parameter
>  is irrelevant for protocols without port numbers.
> 
>  side, the same corresponding process occurs and as a result is able
>  to send the packet via an appropriate uplink transport.
> 
>  a DSA-REQ (802.16 MAC) message. One of the TLVs in the DSA-REQ 
> message is called "CS Specification. This parameter specifies the CS 
> that the connection being set up shall use. The values in this TLV 
> are: 0: No CS 1: Packet, IPv4 2: Packet, IPv6 3: Packet, 
> 802.3/Ethernet 4: Packet, 802.1Q VLAN 5: Packet, IPv4 over 
> 802.3/Ethernet 6: Packet, IPv6 over 802.3/Ethernet 7: Packet, IPv4 
> over 802.1Q VLAN 8: Packet, IPv6 over 802.1Q VLAN 9: ATM 10-255 
> Reserved
> 

Ok.  (previously it was Reg-Req?  Now it's dsa-req/rsp?)

>  when the transport connection is established.

Ok, IPv6 stack doesn't care about which specific CS the underlying MAC
uses.  The IPv6 stack cares about which nd-capable, or non-nd-capable
interfaces are presented to it, and makes its own decisions where to
send packets based on IP tables.

Thanks for the explanation about how the CS intertwinning may work.  It
helps identify where the IPv6 stack is concerned.

Alex

> interoperability, I was wondering what specifically were you 
> concerned about.
> 
> -Raj
> 
> 
> 
> 
> _______________________________________________ 16NG mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/16ng
>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 14 Dec 2006 13:56:51 -0600

Alex,

The IP classifiers that I mentioned in my email are directly from what is
mentioned in the 802.16 specs. So I don't want to argue about the
terminology difference. But I think you get the point.

A host for example essentially can have multiple virtual interfaces over
which IPv6 can be run, right? So in this case it has the ability to choose a
virtual interface which is directly tied to the 802.16 MAC or to 802.3 or to
802.1Q. 

W.r.t the confusion about what Reg-Req does vs DSA-Req:
Reg-Req is used to also indicate capability. The TLV CS capability in the
Reg-Req indicates the capability. And this is useful.
DSA-Req is used to establish a connection as I explained below. So
essentially both messages are applicable. It is a question of the sequence
of messages.
But I think we are going off on a tangent discussing the details of 802.16
MAC. I would rather have you read the 802.16 spec and understand the MAC
details.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Dec 2006 21:14:00 +0100

Basavaraj Patil wrote:
> Alex,
> 
> The IP classifiers that I mentioned in my email are directly from
> what is mentioned in the 802.16 specs. So I don't want to argue about
> the terminology difference. But I think you get the point.

I get some points.

> A host for example essentially can have multiple virtual interfaces
> over which IPv6 can be run, right? So in this case it has the ability
> to choose a virtual interface which is directly tied to the 802.16
> MAC or to 802.3 or to 802.1Q.

Yes, exactly, an IPv6 stack can do that.  Can select between various
interfaces.  And do well.

But I don't think the analogy is ok.

While I see very well an IP stack selecting between all its interfaces I
can't see an IEEE stack doing same thing.

The interoperability question is obvious: how would an IEEE stack switch
between its .16 interface and GPRS for example.  Only IP can do that.

> W.r.t the confusion about what Reg-Req does vs DSA-Req: Reg-Req is
> used to also indicate capability. The TLV CS capability in the 
> Reg-Req indicates the capability. And this is useful. DSA-Req is used
> to establish a connection as I explained below. So essentially both
> messages are applicable. It is a question of the sequence of
> messages.

Which of those delivers the SS link-local address to the AR?  DSA-Req or
Reg-Req.  Please again don't point me to IEEE spec.  If you want you can
find it out, and add it to the IPv6 over IPv6 CS document.

> But I think we are going off on a tangent discussing the details of
> 802.16 MAC. I would rather have you read the 802.16 spec and
> understand the MAC details.

Raj, I'm not sure how things work here.  I bring my level of experience
to the group.  If you think my experience is useful to _your_ document
then it's fine.  If you think it has nothing to do - I'm fine too :-) 
I'll step back.

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 14 Dec 2006 14:58:44 -0600

Alex,

> can't see an IEEE stack doing same thing.

And where did I say that the IEEE stack doing something like that. What I
said was from the IPv6 stack (looking down) you will see multiple virtual
interfaces and the IP stack can choose. You misunderstood my statement.

> between its .16 interface and GPRS for example.  Only IP can do that.

Exactly... And that is what I implied. The IP stack chooses from the
multiple virtual interfaces that it sees.

> find it out, and add it to the IPv6 over IPv6 CS document.

Neither. Why does the AR need the SS' link-local address? You can send an RA
to all-nodes multicast address, right? I recognize where you are coming
from. The point is that the AR sends the RA to a virtual interface which
maps to the MS and is dedicated for that MS only. So the virtual interface
ID is essentially the equivalent of your link-local address in case you are
wondering... But just to be sure, that ID is not the link local-address.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Dec 2006 12:48:38 +0100

Raj, thanks for the reply.

Please allow me to continue on these implementation aspects.

Basavaraj Patil wrote:
>>>  what is mentioned in the 802.16 specs. So I don't want to argue 
>>> about the terminology difference. But I think you get the point.
>> I get some points.
>> 
>>> A host for example essentially can have multiple virtual 
>>> interfaces over which IPv6 can be run, right? So in this case it 
>>> has the ability to choose a virtual interface which is directly 
>>> tied to the 802.16 MAC or to 802.3 or to 802.1Q.
>> Yes, exactly, an IPv6 stack can do that.  Can select between 
>> various interfaces.  And do well.
>> 
>> While I see very well an IP stack selecting between all its 
>> interfaces I can't see an IEEE stack doing same thing.
> 
> And where did I say that the IEEE stack doing something like that. 
> What I said was from the IPv6 stack (looking down) you will see 
> multiple virtual interfaces and the IP stack can choose. You 
> misunderstood my statement.

Ah, I see.  Yes, it is ok for an IP stack to choose among multiple
virtual interfaces.  Do you see ne of those virtual interfaces is IP CS
and the other ETH CS?

So the IP stack puts a packet on one of those interfaces.  The IEEE MAC
layer wouldn't need to distinguish (ie look at the IP fields), the IP
stack told it which packet goes to which interface.  Is this correct?

>> The interoperability question is obvious: how would an IEEE stack 
>> switch between its .16 interface and GPRS for example.  Only IP can
>>  do that.
> 

Ok.

>>> W.r.t the confusion about what Reg-Req does vs DSA-Req: Reg-Req 
>>> is used to also indicate capability. The TLV CS capability in the
>>>  Reg-Req indicates the capability. And this is useful. DSA-Req is
>>>  used to establish a connection as I explained below. So 
>>> essentially both messages are applicable. It is a question of the
>>>  sequence of messages.
>> Which of those delivers the SS link-local address to the AR? 
>> DSA-Req or Reg-Req.  Please again don't point me to IEEE spec.  If 
>> you want you can find it out, and add it to the IPv6 over IPv6 CS 
>> document.
> 
> Neither. Why does the AR need the SS' link-local address? You can 
> send an RA to all-nodes multicast address, right?

The RA needs to have a dst address, I think we agree.  If you send the
RA to all-nodes multicast then the node  that wants to receive that
packet MUST MLD join the all-nodes multicast group prior to receiving it
- otherwise it doesn't receive it.  You said the mobile doesn't send an
MLD join.  Is it automatically joined the IPv6 all-nodes multicast
address once the link is up?

It's strange for AR to send mc RA packets when it knows only one point
is at the other end of the p2p link.

It's strange for SS to automatically be subscribed to a mc group that
will always contain only itself and the AR.

That's why it's important to know what the link-up procedure delivers to
SS and AR.

> I recognize where you are coming from. The point is that the AR sends
>  the RA to a virtual interface which maps to the MS and is dedicated 
> for that MS only. So the virtual interface ID is essentially the 
> equivalent of your link-local address in case you are wondering... 
> But just to be sure, that ID is not the link local-address.

I see.  It looks very much the same when I do IPv6 over GPRS.

However, for what I do over GPRS, it is very clear how that virtual
tunnel interface is set up and what are the link-local addresses
assigned to it.

You seem to say that the way the link (the virtual interface) is set up
is an IEEE procedure and I deduce implicitely the way that virtual
tunnel interface is set up is again an IEEE procedure.

So I would like to ask: is the virtual interface a tunnel interface (an
  IPv6-in-IPv6, v6-in-v4, ip-in-udp)  What's the link-local address of
the virtual interface?  How is it derived (virtual interfaces don't have
MAC addresses).

[If the IPv6 CS were a ppp link then it would have been a real interface
  (not virtual), with real link-local addresses.]

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Fri, 15 Dec 2006 21:14:44 +0200

Alex,

I have some answers to you that should help you to understand these issues.
I also think we could continue this discussion off-line as this seems to be
more informational/tutorial nature.

Please, find my comments below:

>> <[email-masked]> wrote:
[snip]

> address once the link is up?

Where do you get this? If I'm not totally confused, the host is
automatically assigned all-nodes multicast address. In addition, to "join"
the all-nodes multicast the host does not really have to do anything.
Anyways, MLD (Multicast Listener Discovery) is a way for a _router_ to find
out which multicast streams have listeners on its link. IGMP is for a host
to join multicast sessions. Neither of these are used for all-nodes
multicast. All nodes are "automatically" joined to the all-nodes multicast
group.

So, I think either you are or I am confusing something totally.

> is at the other end of the p2p link.

No, it is not. Quite normal. Anyways it does not know how many IP nodes
there are.

> will always contain only itself and the AR.

IMHO, all nodes are naturally joined to the all-nodes multicast

> That's why it's important to know what the link-up procedure delivers to

[snip]

> the virtual interface?  How is it derived (virtual interfaces don't have

Alex, I think we went through a similar discussion couple of months ago. The
interface is real for the IP stack - with a real interface id, and a real
link-local address. Virtual interfaces can have real link-local addresses,
even when the interface id is not derived from a MAC address.

Maybe you're trying to say something else...

>   (not virtual), with real link-local addresses.]

I don't know how PPP fits into this picture in any way. The link-local
address format or "reality" does not change in any way.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Dec 2006 21:24:25 +0100

Soininen Jonne (Nokia-NET/Espoo) wrote:
> Alex,
> 
> I have some answers to you that should help you to understand these 
> issues. I also think we could continue this discussion off-line as 
> this seems to be more informational/tutorial nature.
> 
>> The RA needs to have a dst address, I think we agree.  If you send 
>> the RA to all-nodes multicast then the node  that wants to receive 
>> that packet MUST MLD join the all-nodes multicast group prior to 
>> receiving it - otherwise it doesn't receive it.  You said the 
>> mobile doesn't send an MLD join.  Is it automatically joined the 
>> IPv6 all-nodes multicast address once the link is up?
> 
> automatically assigned all-nodes multicast address.

It's not.

> In addition, to "join" the all-nodes multicast the host does not 
> really have to do anything.

Well, over the Ethernet, the MAC driver somehow joins those groups,
regardless of the IP layer telling it to by MLD JOIN, or not.  Most of
the times it doesn't MLD JOIN.  The IP stack has a call named dev_mcast
with a join parameter, and one always calls that before receiving RAs,
otherwise no RA.  Current implementations don't send an associated MLD
join, but always call that link-layer join.

> Anyways, MLD (Multicast Listener Discovery) is a way for a _router_ 
> to find out which multicast streams have listeners on its link.

Yes, exactly.  Router needs to learn who listens for an RA.

An IP join would theoretically be needed by neighbours too, when they
send NA to link-layer multicast address.

> IGMP is for a host to join multicast sessions.

MLD you mean?

> Neither of these are used for all-nodes multicast. All nodes are 
> "automatically" joined to the all-nodes multicast group.

The IP stack needs to call dev_mcast for that.  You name it
automatically, but I think an MLD join is needed.  Without that
dev_mcast call the IP stack doesn't receive the RA.  The parameters are
multicast link-local groups.

>> It's strange for AR to send mc RA packets when it knows only one 
>> point is at the other end of the p2p link.
> 
> No, it is not. Quite normal. Anyways it does not know how many IP 
> nodes there are.

Not necessarily how many, but to know there's someone listening for it.
  An AR sending an RA to a link where nobody is up is not useful,
badnwidth waste.

>> It's strange for SS to automatically be subscribed to a mc group 
>> that will always contain only itself and the AR.
> 
>> That's why it's important to know what the link-up procedure 
>> delivers to SS and AR.
>> 
> 
> [snip]
> 
>> You seem to say that the way the link (the virtual interface) is 
>> set up is an IEEE procedure and I deduce implicitely the way that 
>> virtual tunnel interface is set up is again an IEEE procedure.
>> 
>> So I would like to ask: is the virtual interface a tunnel interface
>>  (an IPv6-in-IPv6, v6-in-v4, ip-in-udp)  What's the link-local 
>> address of the virtual interface?  How is it derived (virtual 
>> interfaces don't have MAC addresses).
> 
> Alex, I think we went through a similar discussion couple of months 
> ago. The interface is real for the IP stack - with a real interface 
> id, and a real link-local address. Virtual interfaces can have real 
> link-local addresses, even when the interface id is not derived from 
> a MAC address.

YEs.  But.  If the AR has several such virtual interface, one for each
MS connected to it (because p2p links), then all of those virtual
interfaces will all have the same MAC address.   This is what happens in
e.g. bluetooth p2p links, with a bridge software linking those interfaces.

This is not necessarily a good idea (have same MAC address on all
virtual interfaces), especially for DAD, multilink subnets and all that.

Also, interfaces that do have MAC addresses almost always need the IP
stack to add a MAC (Eth MAC) header to it.  Raj says no intermediary
header has the IP stack to build (no .16 MAC header).

This shows me sseveral inconsistencies.  I will not ask you "how is the
interface id derived not from a MAC address" because you will not like it.

>> [If the IPv6 CS were a ppp link then it would have been a real 
>> interface (not virtual), with real link-local addresses.]
> 
> I don't know how PPP fits into this picture in any way. The 
> link-local address format or "reality" does not change in any way.

Ok, let me get back to the ppp discussion.  I was almost convinced ppp
is used, because it has an LCP layer (ConfigReq-Resp), it is used widely
over GPRS/3G/HSDPA (despite other comments, I believe this is true -
I've tried it), has negotiation of link-layer IPv6 IID (not tried, but
documented in PPP IPv6 rfc).  Besides, bluetooth p2p link has a thing
called L2CAP (link-layer negotiation) that also does ConfigReq/Resp, for
some IP-relevant parameters, but currently not supporting IPv6 neither
IPv6's multicast.  For example, most recent version of bluez negotiates
the link-local 'broadcast' capability for IPv4, as 'all-ffs' -
exclusively.  For IPv6 it would need '33:...' instead.

It seems though neither ppp/lcp, nor bluetooth/l2cap are used over
802.16; but the IEEE 802.16 network entry procedure.  So it is in that
network entry procedure that we need to make sure link-local multicast
is supported as "33..." and that is the procedure that should deliver to
the IPv6 stack what ppp or l2cap deliver in other contexts.

This may sound incoherent to you, but I find it logic.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Sun, 17 Dec 2006 23:30:33 +0200

Thanks for the background. It clarified a lot.

However, it does not specifically answer the issue
that I had. This is the same issue that was raised
when the chartering was going on.

Based on your description, I have full confidence
that when at least one transport connection is up,
the stack can deliver a packet through the right
connection. What I am worried about is this:

- How does a host know whether it should initiate
  a connection using CS A or B? Note that the host
  cannot determine anything based on the type
  of packets it wants to deliver on this interface,
  because IPv6 packets can be sent in two ways.

- What if the network supports only CS B but
  client supports only CS A?

--Jari

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 18 Dec 2006 12:51:39 -0600

Hi Jari,

Response inline:

>   because IPv6 packets can be sent in two ways.

I believe this will be implementation specific. Basically if the MS has the
ability to send IPv6 packets via the IP specific part of the packet CS or
via Ethernet (which would send it via the Ethernet specific part of the
packet CS), it would have to choose which of the interfaces to use (maybe
based on some rules/profile/intelligence etc which can be impelemntation
specific). So what you have in essence is a type of multi-homing. So let me
ask you how a host which has multiple interfaces (generically speaking and
nothing to do with .16) which can be used to send/receive IPv6 packets will
decide which interface to choose? It is the same issue.

Now, in the case of WiMAX (which is a realization of a network based on
802.16) the default or mandatory CS required to be supported on hosts and BS
is the IP CS. 

Would a host establish transport connections for both IP CS and Eth CS which
can be used to transport IPv6?
Proably not. Does not make sense. But it is possible.

>   client supports only CS A?

The host in this scenario would not be able to establish a transport
connection since there is a mismatch of the CS'. A host may be able to
perform network entry and attach to the network but would not be able to
send/receive user-data since there is a negotiation of the CS to be used for
the establishment of the transport connection.

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Dec 2006 23:17:50 +0200

> decide which interface to choose? It is the same issue.
This part is probably OK, but it also needs to be
explicitly stated in the draft.
> the establishment of the transport connection.

Right. And that's the interop problem that I was
referring to earlier. At the chartering time we
talked a number of ways to address this:

- Documenting that the different cases are for
  so fundamentally different and disjoint devices
  and deployment scenarios that it just does not
  happen.

- Requiring certain number of options from the
  network side as mandatory-to-implement, such
  that at least from an implementation point of
  view both IPCS and EthCS clients can be
  sure that they will be able to connect to a
  a particular network.

I would actually prefer the latter. But I also
asked Bernard to think about this topic. Bernard,
any thoughts? Would that be sufficient, along
with the negotiations that exist in the link
layer?

--Jari

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 19 Dec 2006 17:33:05 -0800

>Does not make sense.  But it is possible.

I would agree that it does not make sense to require that an implementation 
support multiple sub-interfaces over the same IEEE 802.16 interface, in 
order to handle all the potential combinations.

>with the negotiations that exist in the link

I think the latter approach is preferrable, as long as the MS requirements 
don't become too onerous.
For example, it is easiest if the MS only needs to implement a single 
mechanism;  if the BS is required to implement multiple, then the MS can 
choose any one of them, and interoperability is still possible.  As long as 
the MS only offers a single mechanism, or the BS only accepts one if 
multiple are offered, then we can avoid the problem of multiple 
encapsulations on the same link.

The issue with the first approach is that it requires that we have perfect 
foresight in understanding the potential usage scenarios.  Somehow, the 
Internet always seems to surprise us with technology or usage models that 
noone had thought of beforehand.  For example, while an operator might not 
currently envisage deployment of handsets on their WiMAX network, do we want 
to preclude that usage in case circumstances change?

On the other hand, we need to be careful to not specify too much because in 
a few years, the picture may be simpler than it is today.  Think back to the 
early 1980s with respect to IEEE 802 vs. Ethernet.  That battle was 
decisively won by Ethernet, but that victory was not codified in standards 
until RFC 1122, which was published in October 1989.  In contrast, RFC 894 
(IP over Ethernet) was published in April 1984, and RFC 1042 (IP over IEEE 
802) in February 1988, both as Proposed Standards.  So there was a 
considerable period in which there were multiple standards, before the 
market direction became clear and the simplifications proposed in RFC 1122 
were possible.

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 20 Dec 2006 10:33:28 +0530

I think it is mandatory for BS to support both Ethernet CS and IP CS for
WiMAX networks. If this is the case I do not see any interoperability
problems.

Thanks,
Syam

---

From: Jari Arkko <[email-masked]>
Date: Wed, 20 Dec 2006 08:13:22 +0200

> WiMAX networks. If this is the case I do not see any interoperability
OK. If you add this requirement to the document
that solves the remaining issue from my AD
review.

(But you have to word it carefully. It needs to be a generic
statement, not just Wimax related. Secondly, you do not
want the IP over EthCS document as a normative dependency.)

--Jari

---

From: "Narvaez, Paolo \(Paolo\)" <[email-masked]>
Date: Wed, 20 Dec 2006 21:51:45 -0600

Syam,

Where is it mandated that the Wimax BS must support both Ethernet CS and
IP CS?  I have only seen the requirement for mandatory Ethernet CS in
the case of fixed/nomad usage scenarios (and in that case, IP CS is
optional).

Paolo 

-----Original Message-----
From: Syam Madanapalli [mailto:[email-masked]] 
Sent: Wednesday, December 20, 2006 12:03 AM
To: Jari Arkko
Cc: Bernard Aboba; [email-masked]; [email-masked]
Subject: Re: [16NG] Re: AD review of draft-ietf-16ng-ipv6-over-ipv6cs

Thanks,
Syam

On 12/20/06, Jari Arkko <[email-masked]> wrote:
> >> However, it does not specifically answer the issue that I had. This

> >> is the same issue that was raised when the chartering was going on.
> >>
> >> Based on your description, I have full confidence that when at 
> >> least one transport connection is up, the stack can deliver a 
> >> packet through the right connection. What I am worried about is 
> >> this:
> >>
> > I believe this will be implementation specific. Basically if the MS 
> > has the ability to send IPv6 packets via the IP specific part of the

> > packet CS or via Ethernet (which would send it via the Ethernet 
> > specific part of the packet CS), it would have to choose which of 
> > the interfaces to use (maybe based on some 
> > rules/profile/intelligence etc which can be impelemntation 
> > specific). So what you have in essence is a type of multi-homing. So

> > let me ask you how a host which has multiple interfaces (generically

> > speaking and nothing to do with .16) which can be used to
send/receive IPv6 packets will decide which interface to choose? It is
the same issue.
> >
> This part is probably OK, but it also needs to be explicitly stated in

> the draft.
> > Now, in the case of WiMAX (which is a realization of a network based

> > on
> > 802.16) the default or mandatory CS required to be supported on 
> > hosts and BS is the IP CS.
> >
> > Would a host establish transport connections for both IP CS and Eth 
> > CS which can be used to transport IPv6?

> > connection since there is a mismatch of the CS'. A host may be able 
> > to perform network entry and attach to the network but would not be 
> > able to send/receive user-data since there is a negotiation of the 
> > CS to be used for the establishment of the transport connection.
> >
>
> Right. And that's the interop problem that I was referring to earlier.

> At the chartering time we talked a number of ways to address this:
>
> I would actually prefer the latter. But I also asked Bernard to think 
> about this topic. Bernard, any thoughts? Would that be sufficient, 
> along with the negotiations that exist in the link layer?
>
> --Jari
>
>

---

From: "David Johnston" <[email-masked]>
Date: Wed, 20 Dec 2006 20:21:27 -0800

Paolo,

12.4.2.1 Basic packet PMP MAC profile

Profile identifier: OFDMA_ProfM1.

Mandatory Features:
	- Support of Packet convergence sublayer.
	- Support of Internet Protocol Ipv4.
	- Support IEEE 802.3/Ethernet specific part.
...

This is the basic packet profile in the 802.16 spec, not WiMAX.

I don't know whether to read "Support of Internet Protocol Ipv4." as
requiring the IP specific part, or IPv4 over the 802.3 specific part. It
is vague.

DJ

> From: Narvaez, Paolo (Paolo) [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2006 7:52 PM
> To: Syam Madanapalli; Jari Arkko
> Subject: RE: [16NG] Re: AD review of draft-ietf-16ng-ipv6-over-ipv6cs
> 
> 
> Syam,
>

---

From: "Narvaez, Paolo \(Paolo\)" <[email-masked]>
Date: Thu, 21 Dec 2006 10:28:35 -0600

David, thanks for the information.

However, since the Wimax forum is so far making Eth CS an optional
feature (except for the fixed/nomadic case), it is very likely that
there will be Wimax-certified networks out there that will not support
Eth CS and will be incompatible with Eth CS clients. The I-D should not
assume that both CSs are always available on any network.

Paolo

-----Original Message-----
From: David Johnston [mailto:[email-masked]] 
Sent: Wednesday, December 20, 2006 11:21 PM
To: [email-masked]
Subject: RE: [16NG] Re: AD review of draft-ietf-16ng-ipv6-over-ipv6cs

Paolo,

Mandatory Features:

DJ