Subject: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Oct 2006 22:34:37 +0200

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. This draft is a work item of the IP over IEEE 802.16 
> Networks Working Group of the IETF.
> 
> Title		: IPv6 Over IPv6 Convergence sublayer in WiMAX Networks 
> Author(s)	: B. Patil, et al. Filename	: 
> draft-ietf-16ng-ipv6-over-ipv6cs-00.txt Pages		: 20 Date		: 
> 2006-10-16  The WiMAX forum is defining the network architecture 
> which enables Internet connectivity to mobile stations and IP hosts 
> via the 802.16d/e radio interface.  This document specifies the 
> addressing and operation of IPv6 for hosts served by a WiMAX network.
>  It recommends the assignment of a unique prefix to each host and 
> allow the host to use multiple identifiers within that prefix, 
> including support for randomly generated identifiers.  IPv6 operation
>  in WiMAX networks as explained in this document is based entirely on
>  existing IETF specifications.  The solution entailed herein is 
> recommended for adoption by the WiMAX forum for IPv6 over the IPv6 
> convergence sublayer.

Thanks for the draft.

> From an IPv6 perspective the MS and the AR are connected by a point-
>  to-point link.

Thus, is the RFC2472 IPv6 over point-to-point protocol used by WiMax
mobile stations?

> The IPv6 link between the mobile station (MS) and the access router 
> (AR) is considered as a point-to-point link.  Assignment of a unique
>  prefix per MS is recommended in this document.

Could there be a discussion about address waste which may occur when
each mobile is using a different 64bit prefix?  And the redundancy of
using a unique MAC address when the prefix is guaranteed unique, and
vice-versa?

I'd be inclined to suggest a common prefix be shared among several
mobile stations, each with its unique 64bit IID.

I'd speculate that few operators will enjoy the luxury to assign one 
64bit prefix per mobile it operates.  A cell operator operating 4 
million mobiles, would need a /32 prefix assigned to it by a regional 
registry... while a /48 is considered luxury already.  Or maybe other 
allocation schemes are planned?  What are these?

> The WiMAX forum [WMF] has specified the SDU size as 1522 octets.

Is the MN-AR link symmetric?  Is the SDU the same in both directions?
I'm asking because some cellular mobile links are asymmetric,
privileging the downlink with larger MTU and the upload with smaller MTU.

Alex
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Tue, 17 Oct 2006 00:56:53 +0300

Hi,

> [email-masked] wrote:
[snip] 
> allocation schemes are planned?  What are these?

Actually this is how current cellular networks (3GPP and 3GPP2) work. This
is also what IETF suggested already quite some time ago for 3GPP to take as
the model (RFC3314) and change it from the /128 model. If you don't find the
reasoning for the /64 there (privacy addresses, IPv6 being designed to
actually work better this way, etc.), I'm happy to discuss more about this -
however not necessarily in the context of this WG as we just had a consensus
call on this.

You shouldn't be worried about addresses running out. The default allocation
currently for an operator is /32. That's 4 _billion_ addresses. And if an
operator runs out of those - they can ask for another /32.

> privileging the downlink with larger MTU and the upload with smaller MTU.

I believe it is symmetric. At least 3GPP links are also symmetric (1500b by
the specification).

Does some cellular network have asymmetric MTU in your experience? How is
that treated by the IP stack?

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

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

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 17 Oct 2006 08:46:13 +0900

Just for clarification ...

Is there any consensus (call) to make this draft as the WG document ?

Thanks
Myung-Ki,

[email-masked] wrote:
> directories.
> This draft is a work item of the IP over IEEE 802.16 Networks Working Group of the IETF.
> 
> 	Author(s)	: B. Patil, et al.
> 	Filename	: draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
> 	Pages		: 20
> 	Date		: 2006-10-16
> 	
> The WiMAX forum is defining the network architecture which enables
>    Internet connectivity to mobile stations and IP hosts via the
>    802.16d/e radio interface.  This document specifies the addressing
>    and operation of IPv6 for hosts served by a WiMAX network.  It
>    recommends the assignment of a unique prefix to each host and allow
>    the host to use multiple identifiers within that prefix, including
>    support for randomly generated identifiers.  IPv6 operation in WiMAX
>    networks as explained in this document is based entirely on existing
>    IETF specifications.  The solution entailed herein is recommended for
>    adoption by the WiMAX forum for IPv6 over the IPv6 convergence
>    sublayer.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-ietf-16ng-ipv6-over-ipv6cs-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Tue, 17 Oct 2006 09:16:16 +0900

Myungki,

Given the announcement below, we tried to take folks understanding to
progress this deliverable as quickly as planced for 16ng milestone.

====[pasted from the previous note by Chairs]====

Even though we have not had an official adoption call on the
ipv6-over-ipv6cs document, we went ahead and made it official for
several reasons:

- we need to meet the deadline for submission as an official -00 draft
this Monday, otherwise we won't make our target
- we are in a hurry to get it approved and then to issue WG LC in
order to meet our targets as very recently revised in our milestones
(all 3 of these going to WG LC in October)
- ipv6-over-ipv6cs derives from the previous only draft on per-MS
prefix model (draft-xia-16ng-per-ms-prefix-nd-00) and the editors are
committed to aligning with the latest understanding and with the wimax
efforts.
- (in particular for the latter) we would like to meet the target on
the ipv6cs document as this would also meet the wimax deadlines as
well. Doing so would align us with an important consumer of this
document.

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 17 Oct 2006 09:25:33 +0900

Dainel,

I didn't see the note below.
Did you send the note to the list ([email-masked]) ?

Thanks,
Myung-Ki,

---

From: "Soohong Daniel Park" <[email-masked]>
Date: Tue, 17 Oct 2006 09:28:12 +0900

Sure,

In the achives box:
http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20061009/000293.html

--

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 11:07:09 +0200

Soininen Jonne (Nokia-NET/Espoo) wrote:
>>> The IPv6 link between the mobile station (MS) and the access 
>>> router (AR) is considered as a point-to-point link.  Assignment 
>>> of a unique prefix per MS is recommended in this document.
>> Could there be a discussion about address waste which may occur 
>> when each mobile is using a different 64bit prefix?  And the 
>> redundancy of using a unique MAC address when the prefix is 
>> guaranteed unique, and vice-versa?
>> 
>> I'd speculate that few operators will enjoy the luxury to assign 
>> one 64bit prefix per mobile it operates.  A cell operator operating
>>  4 million mobiles, would need a /32 prefix assigned to it by a 
>> regional registry... while a /48 is considered luxury already.  Or
>>  maybe other allocation schemes are planned?  What are these?
>> 
> 
> Actually this is how current cellular networks (3GPP and 3GPP2) work.

You mean for 3GPP/3GPP2 IPv4?  I agree they so work for IPv4.  But that
is possible in IPv4 only because private non-routable addresses exist in
IPv4 - they don't exist in IPv6.  In one particular IPv4 cellular
network each mobile gets a 10.x.x.x/8 prefix.  But that is possible only
because it's a 10 non-routable address.

I don't think operators are inclined to build closed dedicated IPv6
systems where the mobiles are not reachable from the Internet.

> This is also what IETF suggested already quite some time ago for 3GPP
>  to take as the model (RFC3314) and change it from the /128 model.

I wouldn't be so sure about that recommendation.  It's an INFORMATIONAL
draft (not BCP), it's for 3gpp (not WiMax), it works with site-locals
(they're deprecated) and finally it directs the reader to IAB/IESG and
APNIC/ARIN/RIPE for IPv6 address assignment and allocation policies.

> If you don't find the reasoning for the /64 there (privacy addresses,
>  IPv6 being designed to actually work better this way, etc.), I'm 
> happy to discuss more about this - however not necessarily in the 
> context of this WG as we just had a consensus call on this.

Oh!  Sorry about missing that.  Ok.

> You shouldn't be worried about addresses running out. The default 
> allocation currently for an operator is /32. That's 4 _billion_ 
> addresses.

Yes, I had it wrong thinking /32 is 4 million.

> And if an operator runs out of those - they can ask for another /32.

Exactly - at which point operator is subject to RIR policy of
allocation, not to a INFORMATIONAL RFC.

>> Is the MN-AR link symmetric?  Is the SDU the same in both 
>> directions? I'm asking because some cellular mobile links are 
>> asymmetric, privileging the downlink with larger MTU and the upload
>>  with smaller MTU.
> 
> I believe it is symmetric. At least 3GPP links are also symmetric 
> (1500b by the specification).

YEs, maybe 3gpp links, but this is wimax, right?

> Does some cellular network have asymmetric MTU in your experience?

YEs, some GPRS and UMTS.

> How is that treated by the IP stack?

Fragmentation for uploading and non-fragmentation for downloading (from
mobile's perspective).

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Tue, 17 Oct 2006 13:35:15 +0300

Hi Alex,

[snip] 
> systems where the mobiles are not reachable from the Internet.

The 3GPP/3GPP2 specifications say that you allocate a /64 per mobile in
IPv6. The assumption is that the addresses would be of global scope.

> APNIC/ARIN/RIPE for IPv6 address assignment and allocation policies.

The recommendation is meant for IPv6 addresses in general without regarding
the scope. In addition, you are right - it is an informational document.
This was because there is no real way for IETF to mandate anything on other
standards bodies, and this document is a _recommendation_, which 3GPP
decided to follow - because it makes sense.

It is also true that the document was written before the deprecation of the
site-local addresses. However, that has no impact on the content of the
recommendation - or to this discussion.

> allocation, not to a INFORMATIONAL RFC.

I'm pretty sure I didn't say that RFC3314 would mandate address allocation
policies - the RIR policies mandate that. However, I fail to see the
relevance to this discussion.

> YEs, maybe 3gpp links, but this is wimax, right?

To my understanding, Wimax links are symmetric in the case of MTU size.
>> Does some cellular network have asymmetric MTU in your experience?

In GPRS/UMTS the MTU is symmetric. If you have other experiences, they must
be due to some failure in implementation/configuration. GPRS MTU is 1500 for
IP and 1502 for PPP-

> Fragmentation for uploading and non-fragmentation for downloading (from

Maybe I'm confused, but usually links have just one MTU. This is the case
also for 2G/3G GPRS.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 14:03:02 +0200

Hi Jonne, thanks for the reply.

Soininen Jonne (Nokia-NET/Espoo) wrote:
>> You mean for 3GPP/3GPP2 IPv4?  I agree they so work for IPv4.  But
>>  that is possible in IPv4 only because private non-routable 
>> addresses exist in IPv4 - they don't exist in IPv6.  In one 
>> particular IPv4 cellular network each mobile gets a 10.x.x.x/8 
>> prefix.  But that is possible only because it's a 10 non-routable 
>> address.
>> 
> The 3GPP/3GPP2 specifications say that you allocate a /64 per mobile
>  in IPv6. The assumption is that the addresses would be of global 
> scope.

Thanks, that is good to know, and confirms some of my expectations.  Is 
there any deployment of the 3GPP/3GPP2 specifications that say you
allocate a /64 per mobile in IPv6, and the addresses are global scope?

>>> This is also what IETF suggested already quite some time ago for
>>>  3GPP to take as the model (RFC3314) and change it from the /128
>>>  model.
>> I wouldn't be so sure about that recommendation.  It's an 
>> INFORMATIONAL draft (not BCP), it's for 3gpp (not WiMax), it works
>>  with site-locals (they're deprecated) and finally it directs the 
>> reader to IAB/IESG and APNIC/ARIN/RIPE for IPv6 address assignment
>>  and allocation policies.
> 
> The recommendation is meant for IPv6 addresses in general without 
> regarding the scope.

Well, the document title is "IPv6 for Some Second and Third Generation
Cellular Hosts" and makes extensive use of "PDP context" term.

Is WiMax host a cellular host?  Is a WiMax terminal using "PDP contexts".

> In addition, you are right - it is an informational document. This 
> was because there is no real way for IETF to mandate anything on 
> other standards bodies, and this document is a _recommendation_, 
> which 3GPP decided to follow - because it makes sense.
> 
> It is also true that the document was written before the deprecation
>  of the site-local addresses. However, that has no impact on the 
> content of the recommendation - or to this discussion.
> 
>>> If you don't find the reasoning for the /64 there (privacy 
>>> addresses, IPv6 being designed to actually work better this way,
>>>  etc.), I'm happy to discuss more about this - however not 
>>> necessarily in the context of this WG as we just had a consensus
>>>  call on this.
> I'm pretty sure I didn't say that RFC3314 would mandate address 
> allocation policies - the RIR policies mandate that. However, I fail
>  to see the relevance to this discussion.
> 
>>>> asymmetric, privileging the downlink with larger MTU and the 
>>>> upload with smaller MTU.

On paper or in practice?

> In GPRS/UMTS the MTU is symmetric. If you have other experiences, 
> they must be due to some failure in implementation/configuration.

"Failure"?  I regret to see it termed as "failure", and relegated to
some implementation configuration.  To me, it is a disconnect between
specification and implementation.  The "failure" may be in the
specification too.

> GPRS MTU is 1500 for IP and 1502 for PPP-
> 
>> Fragmentation for uploading and non-fragmentation for downloading 
>> (from mobile's perspective).
> 
> Maybe I'm confused, but usually links have just one MTU. This is the
>  case also for 2G/3G GPRS.

Yes, I agree in general we talk links have one MTU.

However, many cellular wireless links are asymmetric in nature, the
download pipe is wider - because the typical use is to download content
(not to upload).  This can be seen easily with stacks that fragment
outgoing packets because their next-hop routers tells them do so.

Finally, I agree with you that IP-friendly MAC-enabled IEEE 802 links
are easier to specify and implement with symmetric MTU.

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Tue, 17 Oct 2006 15:33:36 +0300

Alex,

On 10/17/06 3:03 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:
[snip]
> allocate a /64 per mobile in IPv6, and the addresses are global scope?

Many phone and network implementations support this (this is how IPv6 is
supported). I don't know if there are any commercial deployments of IPv6
over 3GPP/3GPP2 networks.

[snip]
> Is WiMax host a cellular host?  Is a WiMax terminal using "PDP contexts".

I didn't say that RFC3314 is recommending what Wimax is supposed to do. At
the time of the writing of RFC3314 Wimax did not really exist, yet.

However, the arguments why /64 should be given instead of /128 still hold.

> On paper or in practice?

Mobile Wimax is in the specification phase. Fixed deployments already exist.
To my understanding the MTU is symmetric.
 
> specification and implementation.  The "failure" may be in the

As interesting as it is, I would not like to start a discussion about the
philosophy of standards vs. Implementations that are not compliant to the
standard they are supposed to implement. I'm sure we can discuss this over a
beer some day rather than on this list.

However, GPRS (both for GSM-radio and WCDMA) has the MTU of 1500 for IP.

> outgoing packets because their next-hop routers tells them do so.

The bandwidth on wireless links are usually asymmetric. That is true.
However, this has nothing to do with the MTU. Also many fixed links are
asymmetric (ADSLs generally are). However, the MTU is still the same for
down and uplink. 
In addition, the next hop router would have issues of telling the mobile to
fragment as the packets needing fragmentation would never reach the
first-hop router. 

Anyways, I'm not sure if this discussion is related to this mailing list.

Cheers,

Jonne. 

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 15:18:04 +0200

Soininen Jonne (Nokia-NET/Espoo) wrote:
> <[email-masked]> wrote: [snip]
>>> The 3GPP/3GPP2 specifications say that you allocate a /64 per 
>>> mobile in IPv6. The assumption is that the addresses would be of
>>>  global scope.
>> Thanks, that is good to know, and confirms some of my expectations.
>>  Is there any deployment of the 3GPP/3GPP2 specifications that say
>>  you allocate a /64 per mobile in IPv6, and the addresses are
>> global scope?
> 
> Many phone and network implementations support this (this is how IPv6
>  is supported).

Well, some IPv6 stack implementations on phone do support one IPv6
prefix shared among several mobiles, over an IPv4 GPRS.

> I don't know if there are any commercial deployments of IPv6 over 
> 3GPP/3GPP2 networks.
[snip]
> To my understanding the MTU is symmetric.

Well, this IPv6 CS document talks about the IPv6 link of MS mobile 
station.  It makes a specific recommendation of MTU to be 1400.  This 
can be seen in-line with rfc2460 suggestion that the MTU be 1280 or 
larger.  If ppp links used, it suggests to go up to 1500.  I think the 
IPv6 CS document should consider ppp links (IPv6 PPP) because these 
exist and can be tested in practice.

> I didn't say that RFC3314 is recommending what Wimax is supposed to 
> do. At the time of the writing of RFC3314 Wimax did not really exist,
>  yet.
> 

And the address waste argument also holds.

>> "Failure"?  I regret to see it termed as "failure", and relegated 
>> to some implementation configuration.  To me, it is a disconnect 
>> between specification and implementation.  The "failure" may be in
>>  the specification too.
> 
> As interesting as it is, I would not like to start a discussion about
>  the philosophy of standards vs. Implementations that are not 
> compliant to the standard they are supposed to implement. I'm sure we
>  can discuss this over a beer some day rather than on this list.

:-)

>>  download pipe is wider - because the typical use is to download 
>> content (not to upload).  This can be seen easily with stacks that
>>  fragment outgoing packets because their next-hop routers tells
>> them do so.
> 
>  However, this has nothing to do with the MTU.

It has been noticed that some wireless links are asymmetric: both
bandwidth and MTU.

> Also many fixed links are asymmetric (ADSLs generally are). However,
>  the MTU is still the same for down and uplink.

Yes for ADSL.

> In addition, the next hop router would have issues of telling the 
> mobile to fragment as the packets needing fragmentation would never 
> reach the first-hop router.

Somehow yes.  How about the next-hop router receiving the packets but
refusing to forward them and send 'packet too big' to mobile.  How about 
the next-hop router acting so because its wireless link has a 
configurable MTU.

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Tue, 17 Oct 2006 17:20:38 +0300

Alex,

On 10/17/06 4:18 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:

[snip]

> larger.

Yes, this is because GRE tunneling is often used in the corenetwork in
Wimax. So, 1500 + GRE + IP > 1500 (usually the MTU in ethernet). 1400 is
safer as the tunneled packets won't get fragmented.
  
> If ppp links used, it suggests to go up to 1500.  I think the

PPP is usually run directly over layer 2 (e.g. Modem lines). Thus, there is
not tunneling overhead.

I guess, PPP is anyways out of the scope of this discussion as we are
talking about the IEEE/Wimax Forum specifies IP convergence sub-layer IPCS.

> And the address waste argument also holds.

This was intensively discussed in the interim meeting. However, in IPv6 you
should count "addresses". You should count prefixes. /64 is practically the
smallest prefix for architectural reasons of IPv6.

The address argument does not hold. First of all, there are enough
addresses. Secondly, a lot of functionality in the IPv6 stacks rely on
having a prefix - not a single address. As an example, privacy addresses is
one of these. In addition, having a shared prefix causes a lot of additional
issues. For instance, neighbor discovery does not work without additional
functionality in the network and there is a risk it would not work at all.
Thus, the prefix per MS model was chose.

Anyways, we should stop discussing this as the chairs will soon inform us
that we are out of scope as this was already decided by the consensus call
(you can check it from the archives).

[snip]
> It has been noticed that some wireless links are asymmetric: both

This statement is very general. At least the implementations I know, use
symmetric MTU.

[snip]
> the next-hop router acting so because its wireless link has a

The next hop router is behind the wireless link. Thus, your packet has
already traveled over the air and has reached a router. It can be that the
links behind the router have a smaller MTU than the one you used, for
instance. Then the ICMP error is not about the wireless link, but the links
behind the first-hop router.

I hope this helps,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 17:00:03 +0200

Soininen Jonne (Nokia-NET/Espoo) wrote:
>> If ppp links used, it suggests to go up to 1500.  I think the IPv6
>>  CS document should consider ppp links (IPv6 PPP) because these 
> PPP is usually run directly over layer 2 (e.g. Modem lines). Thus, 
> there is not tunneling overhead.

You mean CS is not layer 2?  PPP runs over PDP contexts (which are layer
2), PPP's L2CP (layer-2 control protocol) sets up PDP contexts and
negotiates the 64bit interface identifier to be used in forming the IPv6
link-local address.  This is specified in RFC 2472.

I believe IPv6 ppp implementation is used by the prototypical 3gpp IPv6
tryouts (I may be corrected on this particular statement - it's my
speculation).

>  talking about the IEEE/Wimax Forum specifies IP convergence 

As long as IPCS is not a true MAC (and it can't be because physical
constraints of MAN vs LAN) - the link to the mobile will be
point-to-point in nature, and PPP is for it.

I think we should discuss implementation here, or implementation trends.
  For example, do we know whether an IPCS implementation trend tends to
consider PPP implementation, or not.  Not IPCS emulation, but IPCS
implementation.

>>> I didn't say that RFC3314 is recommending what Wimax is supposed
>>>  to do. At the time of the writing of RFC3314 Wimax did not
>>> really exist, yet.
>>> 
> This was intensively discussed in the interim meeting. However, in 
> IPv6 you should count "addresses". You should count prefixes. /64 is
>  practically the smallest prefix for architectural reasons of IPv6.

While I agree the /64 is smallest prefix for architectural reasons in
IPv6 I strongly disagree with the remark that I should not count
addresses and count prefixes instead.  It spells address waste.

IPv6 PPP generates 64bit Interface ID.  If a PPP server is capable to
negotiate unique IIDs to all its clients then it's natural to share a
unique /64 prefix among all those clients - it's sure the resulting
128bit addresses are unique.  Doing so would avoid reserving one /64 bit
per mobile, and implicitely more efficiently used address space.

> addresses. Secondly, a lot of functionality in the IPv6 stacks rely 
> on having a prefix - not a single address. As an example, privacy 
> addresses is one of these.

The privacy perspective is different when we consider that the PPP
server gives the client an Interface ID.  The privacy concern was raised
when it was considered that the IID comes from the client, and it was
hardcoded in its ethernet card.  With PPP it's negotiated with the server.

> In addition, having a shared prefix causes a lot of additional 
> issues. For instance, neighbor discovery does not work without 
> additional functionality in the network and there is a risk it would 
> not work at all.

Neighbour Discovery incarnation on a point to point link is  different
than on a shared link.  All ND functionalities designed for shared links
are not needed on point to point links.  Example, a p2p host does not
need to send unsolicited NAs (as part of DAD) because it's sure its
unique IID comes from first-hop trusted source.  When the host and
router are sure it's a point to point link the ND becomes a much smaller
incarnation.

Another example: as part of PPP connection setup the MTU and default
router address are communicated to the host.  They do not need to be
communicated to it again in an RA, so the RA could be smaller.

> Thus, the prefix per MS model was chose.

Well, I generally respect WG decision.  In this case I'd ask the WG
whether there's any implementation plan or trend for CS or IPCS and
whether that uses or not PPP.

> Anyways, we should stop discussing this as the chairs will soon 
> inform us that we are out of scope as this was already decided by the
>  consensus call (you can check it from the archives).

YEs, I'll try do that.

>>>  mobile to fragment as the packets needing fragmentation would 
>>> never reach the first-hop router.
>> Somehow yes.  How about the next-hop router receiving the packets 
>> but refusing to forward them and send 'packet too big' to mobile. 
>> How about the next-hop router acting so because its wireless link 
>> has a configurable MTU.
> 
> The next hop router is behind the wireless link. Thus, your packet 
> has already traveled over the air and has reached a router. It can be
>  that the links behind the router have a smaller MTU than the one you
>  used, for instance. Then the ICMP error is not about the wireless 
> link, but the links behind the first-hop router.

It would be unreasonable for links behind the first-hop router to have a
smaller MTU than the wireless link.  Core network links usually have
much higher bandwidth and MTU than edge links, right.

If a host is attached to a link whose MTU is smaller than what the
host's stack tries to send - who's to tell the host to run PMTU?

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Thu, 19 Oct 2006 17:18:43 +0300

Alex,

Your last mail to the list triggered my response to this as well. I will,
however, address your last mail separately.

Some more comments below:

On 10/17/06 6:00 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:
[snip]
> link-local address.  This is specified in RFC 2472.

There are three PDP Context types in the 3GPP systems (2G/3G GPRS): PDP Type
IPv4, PDP Type IPv6, and PDP Type PPP. Only the PDP Type PPP uses PPP. There
are different tutorials of 3GPP systems. If you want, I could look if I
would find some of them on-line.

> tryouts (I may be corrected on this particular statement - it's my

The non-prototypical implementations of IPv6 I know use PDP Type IPv6.

> point-to-point in nature, and PPP is for it.

I don't know what you mean by a true MAC. However, there are also other
examples outside 802.16 that have similar link-model and are not using PPP
(3GPP/3GPP2 systems, for example).

The IPCS was designed to carry directly IP packets without PPP. Thus, PPP is
out of question.

> consider PPP implementation, or not.  Not IPCS emulation, but IPCS

I'm not sure what you mean here. However, I'm just saying how the specs
work. The implementations are done based on the specs. Also my examples from
3GPP are based on commercial implementations.

Maybe you mean something else?

[snip]
> addresses and count prefixes instead.  It spells address waste.

IPv6 addresses are not like IPv4 addresses. Thus, what you call waste is an
intended behavior for IPv6.

> per mobile, and implicitely more efficiently used address space.

Yes, using PPP you can generate unique IIDs - no question about it. However,
it restricts features from the IPv6 stack (e.g. Usage of Privacy addresses).
Thus, giving just a /128 for a mobile is not optimal.

> hardcoded in its ethernet card.  With PPP it's negotiated with the server.

Privacy addresses are not only intended to hide the Ethernet MAC address.
They also can be used to make tracking of an individual host visiting e.g.
some web sites harder.

> communicated to it again in an RA, so the RA could be smaller.

I'm aware how ND and PPP work. However, like I said, this is about IPCS not
PPP. It is the intention to make the IPCS to look as standard as possible,
and there per MS-prefix does the job better.
 
> whether that uses or not PPP.

It does not use PPP. Hence, the name IPCS.

[snip]
> host's stack tries to send - who's to tell the host to run PMTU?

Perhaps the links on the wireless are usually have smaller MTU than fixed
links. However, the examples we have discussed here have the MTU of 1500,
which is a common MTU also in the fixed links. In addition, it seems that
you have found a case where the link MTU in the core network actually is
smaller than the MTU.

If a host is attached to a link, which MTU is smaller than set in the host
stack you have a configuration problem. The MTU of the stack should be equal
of smaller than the link MTU. Path-MTU is run over multiple links (a path)
where there might be different MTUs. The local MTU should be known by the
host.

Cheers,

Jonne. 

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Oct 2006 17:31:27 +0200

Soininen Jonne (Nokia-NET/Espoo) wrote:
>> You mean CS is not layer 2?  PPP runs over PDP contexts (which are 
>> layer 2), PPP's L2CP (layer-2 control protocol) sets up PDP 
>> contexts and negotiates the 64bit interface identifier to be used 
>> in forming the IPv6 link-local address.  This is specified in RFC 
>> 2472.
> 
> There are three PDP Context types in the 3GPP systems (2G/3G GPRS): 
> PDP Type IPv4, PDP Type IPv6, and PDP Type PPP. Only the PDP Type PPP
>  uses PPP. There are different tutorials of 3GPP systems. If you
> want, I could look if I would find some of them on-line.

Thanks but no, please save the time.  I am interested if there's any
tutorial about the implementation of these systems, not on the specs.

>> I believe IPv6 ppp implementation is used by the prototypical 3gpp 
>> IPv6 tryouts (I may be corrected on this particular statement - 
>> it's my speculation).
> 

Do they use L2CP IPv6 PPP RFC2472?

>>> I guess, PPP is anyways out of the scope of this discussion as we
>>>  are talking about the IEEE/Wimax Forum specifies IP convergence
>>>  sub-layer IPCS.
> I don't know what you mean by a true MAC. However, there are also 
> other examples outside 802.16 that have similar link-model and are 
> not using PPP (3GPP/3GPP2 systems, for example).
> 
> The IPCS was designed to carry directly IP packets without PPP. Thus,
>  PPP is out of question.
> 
>> I think we should discuss implementation here, or implementation 
>> trends. For example, do we know whether an IPCS implementation 
>> trend tends to consider PPP implementation, or not.  Not IPCS 
>> emulation, but IPCS implementation.
> 
> I'm not sure what you mean here. However, I'm just saying how the 
> specs work. The implementations are done based on the specs. Also my 
> examples from 3GPP are based on commercial implementations.
> 

Sorry, I'm afraid I can't contribute any further for the above
paragraphs.  I don't have that much knowledge on this topic that you
seem to have.

>>> This was intensively discussed in the interim meeting. However, 
>>> in IPv6 you should count "addresses". You should count prefixes. 
>>> /64 is practically the smallest prefix for architectural reasons 
>>> of IPv6.
>> While I agree the /64 is smallest prefix for architectural reasons 
>> in IPv6 I strongly disagree with the remark that I should not count
> IPv6 addresses are not like IPv4 addresses. Thus, what you call waste
>  is an intended behavior for IPv6.

Huh?  That may be interpreted as revolutionary :-)

>> IPv6 PPP generates 64bit Interface ID.  If a PPP server is capable 
>> to negotiate unique IIDs to all its clients then it's natural to 
>> share a unique /64 prefix among all those clients - it's sure the 
>> resulting 128bit addresses are unique.  Doing so would avoid 
>> reserving one /64 bit per mobile, and implicitely more efficiently 
>> used address space.
> 
> Yes, using PPP you can generate unique IIDs - no question about it. 
> However, it restricts features from the IPv6 stack (e.g. Usage of 
> Privacy addresses).

Private addresses are not restricted in any way if the operator decides
what the address looks like.  This type of operator prefers the address
to be private to the user from another user but not from itself.

> Thus, giving just a /128 for a mobile is not optimal.

Let me turn the question differently: does the operator of a mobile
terminal prefer the user of the terminal to use its per-mobile prefix to
actually use several of such terminals (in a PAN moving network)?  The
user could derive many many addresses from a per-mobile prefix that is
allocated.  The operator usually doesn't like that.

>>> The address argument does not hold. First of all, there are 
>>> enough addresses. Secondly, a lot of functionality in the IPv6 
>>> stacks rely on having a prefix - not a single address. As an 
>>> example, privacy addresses is one of these.
>>  server gives the client an Interface ID.  The privacy concern was 
>> raised when it was considered that the IID comes from the client, 
>> and it was hardcoded in its ethernet card.  With PPP it's 
>> negotiated with the server.
> 
> Privacy addresses are not only intended to hide the Ethernet MAC 
> address. They also can be used to make tracking of an individual host
>  visiting e.g. some web sites harder.

There are web anonymizers for that.

Changing her/his address periodically (and without MIP6) leads to VoIP
sessions being interrupted.

End users sometimes want privacy other times reachability.  Let this
fundamental decision to end user not delegate to network.

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Thu, 19 Oct 2006 20:14:56 +0300

Alex,

On 10/19/06 6:31 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:
[snip]
> tutorial about the implementation of these systems, not on the specs.

The specs specify how the networks work. So, the information is accurate. I
don't think there is any public information about
how-to-implement-a-3gpp-network. However, I'm sure you can try to ask your
company as you do build both networks and handsets.

Anyways, this is besides the point for this list. (Sorry for the long trail
of messages, everybody!)
> Do they use L2CP IPv6 PPP RFC2472?

No.

[snip] 

> Huh?  That may be interpreted as revolutionary :-)

I don't think so.

> to be private to the user from another user but not from itself.

I mean privacy addresses such as RFC3041.

> allocated.  The operator usually doesn't like that.

The operators don't have a problem with giving /64 in 3GPP/3GPP2 networks
either.

> sessions being interrupted.

As you know, in IPv6 the host can have multiple addresses on the same
interface. Using RFC3041 does not preclude you to let go of your stable
address.

> fundamental decision to end user not delegate to network.

That's why the decision should be left for the host, not the network.

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 19 Oct 2006 20:33:13 +0200

Jonne, thanks for your email.  In general your emails on this thread to
me helped me better understand some aspects of this draft.  Please let
me clarify just a few points, below.

Soininen Jonne (Nokia-NET/Espoo) wrote:
>> Thanks but no, please save the time.  I am interested if there's 
>> any tutorial about the implementation of these systems, not on the 
>> specs.
> 
> The specs specify how the networks work. So, the information is 
> accurate.

This is simply not true.  We do not currently know how these networks
work.  We write specs about how we would like them to work.

I've asked the variable MTU question and you replied with the 3GPP spec.
  Do we know a WiMax trial/plan doing equal MTU uplink/downlink?

> I don't think there is any public information about 
> how-to-implement-a-3gpp-network. However, I'm sure you can try to ask
>  your company as you do build both networks and handsets.

I'm very surprised by your request.  I take it as a polite invitation
though.

>> Do they use L2CP IPv6 PPP RFC2472?

Good to know.

>>  terminal prefer the user of the terminal to use its per-mobile 
>> prefix to actually use several of such terminals (in a PAN moving 
>> network)?  The user could derive many many addresses from a 
>> per-mobile prefix that is allocated.  The operator usually doesn't 
>> like that.
> 
> The operators don't have a problem with giving /64 in 3GPP/3GPP2 
> networks either.

Let me ask this then: a 3GPP commercial operator giving /64 prefixes to
mobiles - does it ensure their mobiles are reachable from the IPv6 Internet?

>> End users sometimes want privacy other times reachability.  Let 
>> this fundamental decision to end user not delegate to network.
> 
We agree on this one.

Alex

---

From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Date: Fri, 20 Oct 2006 00:19:28 +0300

Alex,

> me clarify just a few points, below.

Good. I hope these can be of use.
 
> work.  We write specs about how we would like them to work.

I don't really understand your comment. We write the specs because that is
how we want the things to work to get interoperability. The networks are
implemented according the specs to make sure there is interoperability.

There are implemented, alive 3GPP networks that work according the specs. It
does not mean that all the features and options are implemented. However,
those that are - are usually according the specs.

Mobile Wimax is a bit of a different thing, though. The specifications are
just being finalized.
>   Do we know a WiMax trial/plan doing equal MTU uplink/downlink?

The 802.16 specs to my knowledge say the MTU is 1522. That is both for
uplink and downlink.

> I'm very surprised by your request.  I take it as a polite invitation

Was supposed to be just a data-point if you needed more information.

[snip]
> mobiles - does it ensure their mobiles are reachable from the IPv6 Internet?

I think Jouni answered you on this already.

Like Jouni, I also feel that this mail threat has served most probably its
purpose by now.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Oct 2006 13:19:12 +0300

Let me just remind everyone that we are in the IP over
802.16 working group. Are the specifics of the 3GPP
design relevant for our discussion here?

And: lets focus on the current ongoing consensus calls
on the documents, not rehashing discussions from
the past ones. I have not yet seen enough reviews
of the IPv6CS document.

--Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Oct 2006 17:18:15 +0200

Jari Arkko wrote:
> Let me just remind everyone that we are in the IP over 802.16 working
>  group. Are the specifics of the 3GPP design relevant for our 
> discussion here?

Sorry, no they aren't much.

I could contribute to any review or discussion around the following:

Is the document title relevant?  The document title "IPv6 Over IPv6
Convergence sublayer in WiMAX Networks" does not seem to appear in the
Charter.

Would it be relevant to separate the document in two: Transmission of
IPv6 over 802.16 networks, and architecture of WiMax.

Would it be relevant to reduce description of what's happening
between BS and AR?

It would be useful to know what does the layer 2 header look like?  Is
there a trailer?  Is it exactly the MAC header of Ethernet?

Can a 802.16 Source link-layer address (or Target) be properly encoded
in ND messages?

Are the bytes put by IP stack on a 802.16 CS respecting network byte
order?  Or not?

What is the value of the eventual type included in the layer 2 header
when transporting IPv6?  Is it 0x86dd?

Uniqueness of 802.16 MAC addresses?  Are they in the same space as
802.11 MAC addresses?

Is 802.16 CS hiding link-layer fragmentation from the IPv6 stack?

How do IPv6 multicast addresses map into 802.16 CS multicast addresses?
  (e.g. 33:33:0:0:0:1 and :2)

Section 8.1 "Router Solicitation"  What is the src address of that RS?

SEction 9.1 "Interface Identifier" could probably picture, for
illustrative purposes, how the IEEE 802.16 MAC address is transformed
into an Interface Identifier for inclusion in IPv6 addresses.  It would
be illustrative  to show an fe80 address derived on that MAC address.

> And: lets focus on the current ongoing consensus calls on the 
> documents, not rehashing discussions from the past ones. I have not 
> yet seen enough reviews of the IPv6CS document.

If comments I've mentioned above have been discussed in the past, sorry,
please ignore this message.

Alex

---

From: "Syam Madanapalli" <[email-masked]>
Date: Fri, 20 Oct 2006 22:58:24 +0530

Some answers inline.

> there a trailer?  Is it exactly the MAC header of Ethernet?

It is different, 802.16 does not carry src and dst MAC headers,
rather carries the CID. Some details can be found in the following
draft, Section 6.1.
http://tools.ietf.org/wg/ipv6/draft-madanapalli-ipv6-over-802.16-ipv6cs-00.txt
(please note that this draft is not relevant here)

> Can a 802.16 Source link-layer address (or Target) be properly encoded

This can be done, but this does not help in anyway, as there always exists
a connection between MS and AR according to Wimax Network definition.

> Are the bytes put by IP stack on a 802.16 CS respecting network byte

I think so.

> when transporting IPv6?  Is it 0x86dd?

There is no such field in 02.16 MAC header.

> Uniqueness of 802.16 MAC addresses?  Are they in the same space as

I think so.

> Is 802.16 CS hiding link-layer fragmentation from the IPv6 stack?

Yes.

>   (e.g. 33:33:0:0:0:1 and :2)

Are there multicast addresses in 802.16?
Or you mean IPv6 multicast address to a multicast CID?
802.16 supports only downlink multicast, so an MS cannot
send a multicast packet unless network explicity maps this incoming
frame to a downlink multicast CID. I think in WiMAX netowkrs, currently
the use of multicast has not been defined.

> Section 8.1 "Router Solicitation"  What is the src address of that RS?

Unspecified address if the host has not  configured the link local address yet.
This behavior should be same as RFC2461bis.

> be illustrative  to show an fe80 address derived on that MAC address.

It is same as Appendix A in RFC 4291 i.e. similar to Ethernet interface.

Thanks,
Syam

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Oct 2006 20:28:43 +0200

Hi Syam, thanks for the reply.  Please allow me to respond, trying on focus.

Syam Madanapalli wrote:
>> It would be useful to know what does the layer 2 header look like?
>>  Is there a trailer?  Is it exactly the MAC header of Ethernet?
> 

Ok, and there seems to be a trailer too (checksum).  I believe the
checksum is computed/verified by the link-layer implementation(?).

So you mean that even with the IPv6 CS there is no intermediary 802.3
Ethernet MAC header between the IPv6 header and the 802.16e MAC header?

>> Can a 802.16 Source link-layer address (or Target) be properly 
>> encoded in ND messages?
> 
> This can be done, but this does not help in anyway, as there always 
> exists a connection between MS and AR according to Wimax Network 
> definition.

I see.  Do you think it's reasonable to try to encode the two-byte CID
into ND messages, as Source and Target link-layer addresses.

>> What is the value of the eventual type included in the layer 2 
>> header when transporting IPv6?  Is it 0x86dd?
> 

Thanks, I've just realized so.  Not even one intermediary 802.3 Ethernet
MAC header between the 802.16e MAC header and the IPv6 header?

>> Is 802.16 CS hiding link-layer fragmentation from the IPv6 stack?

Is there a one-to-one correspondence between an IPv6 fragment header and
  an 802.16e MAC sub-header?  Or probably no correspondence at all?

>> How do IPv6 multicast addresses map into 802.16 CS multicast 
>> addresses? (e.g. 33:33:0:0:0:1 and :2)
> 
> Are there multicast addresses in 802.16? Or you mean IPv6 multicast 
> address to a multicast CID?

I realize the 2-byte CID replaces what I commonly thought is a 6-byte
IEEE MAC address.  If so, and only if no intermediary 802.3 MAC header,
then I think we should have a method to translate a 2-byte CID into an
IID, and build an fe80 address out of that CID, no?

If there are multicast CIDs then we should map the IPv6 mc addresses
into them too, no?

> Unspecified address if the host has not  configured the link local 
> address yet. This behavior should be same as RFC2461bis.

Ok.  Should the link-local address be auto-computed (such as cat IID to
fe80)?  If so does the IID come from the BS?

Is the CID hardcoded in the card (like 48bit MAC addresses)?  Is it
dynamically negotiated?

>> illustrative purposes, how the IEEE 802.16 MAC address is 
>> transformed into an Interface Identifier for inclusion in IPv6 
>> addresses.  It would be illustrative  to show an fe80 address 
>> derived on that MAC address.
> 

Thanks, I think you mean the subsection "Links with Other Kinds of
Identifiers" of that Appendix, which describes "Links Without
Identifiers"?  I believe this 802.16e is a link _with_ identifier (CID),
no?  If yes then again the CID-to-IID mapping would be needed no?

Or the subsection "Links with Other Kinds of Identifiers"?  That
describes LocalTalk and Arcnet, converting the 8bit identifier to an IID.

Alex

---

From: "Syam Madanapalli" <[email-masked]>
Date: Sat, 21 Oct 2006 00:41:31 +0530

Hi,

Quick reply on CID.

CID (Connection Identifier) is assigned dynamically by the ASN GW
in WiMAX  networks when connection is being set up. There can be
multiple connections exists between MS and AR (ASN GW) at any
given time to satisfy different QoS requirements.

So I am not sure if we can use the CID in ND messages for any
real use.

Also it is better if we generate the IID from the MAC address which
is globally unique compared to 16 bit CID which is not globally unique.

Some comments inline.

> checksum is computed/verified by the link-layer implementation(?).

I also think so.

> Ethernet MAC header between the IPv6 header and the 802.16e MAC header?

If Ethernet CS is being used then there will be Ethernet MAC header
between IP header and 802.16 MAC frame.

> into ND messages, as Source and Target link-layer addresses.

May not be of any help as I mentioned at the start.

> IID, and build an fe80 address out of that CID, no?

Actually, according to 802.16 spec, IP addresses is needed to establish
a connection and hence CID; to get the IP address the host needs a
connection, it's like deadlock.
In WiMAX, NWG defined Initial Service Flow to overcome this, which is
an initial CID established as soon as MS completes the network entry
and authorization. I think this initial CID can be modified later to include
the IP address and many more connections can be established, so at
this point which connection to be used for ND messages, and which CID
can be used for IID may not be very clear.

> If there are multicast CIDs then we should map the IPv6 mc addresses

May be, but that use has not yet been defined.

> fe80)?  If so does the IID come from the BS?

IID can be derived from the MAC address or any other method. And Link
Local address configuration is same as that of Ethernet interface type.
One of the goals for the solution is to impose no changes to the normal
IPv6 host implementations, so it should work as defined in RFC 2461/2462.

> Is the CID hardcoded in the card (like 48bit MAC addresses)?  Is it

Nope, it is dynamically created and will be destroyed when not in use.

> describes LocalTalk and Arcnet, converting the 8bit identifier to an IID.

802.16 has MAC address which is globally unique, so I am not
sure if this falls under "Links with Other Kinds of Identifiers".

Thank you,
Syam

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Oct 2006 22:29:24 +0200

Syam Madanapalli wrote:
> Hi,
> 
> Quick reply on CID.
> 
> CID (Connection Identifier) is assigned dynamically by the ASN GW in 
> WiMAX  networks when connection is being set up. There can be 
> multiple connections exists between MS and AR (ASN GW) at any given 
> time to satisfy different QoS requirements.

I believe each such connection would imply a different IP address, no?

> So I am not sure if we can use the CID in ND messages for any real 
> use.

Indeed, if there is no IP address per connection (but a unique IP
address for all connections) then maybe not necessary to encode CID in ND.

Unless, maybe, if there is a maximum number of such connections (maybe
max 4) they could be _all_ encoded in a 64bit IID.  Just a possibility.

The reason to encode CID into IID is probably to make it look like IPv6
LCP PPP, where there is some ID given by the PPP server to the client,
which encodes it into IID.

> is globally unique compared to 16 bit CID which is not globally 

Yes, I agree.

>> So you mean that even with the IPv6 CS there is no intermediary 
>> 802.3 Ethernet MAC header between the IPv6 header and the 802.16e 
>> MAC header?
> 

Ok, this is very different than other IPv6 over point-to-point links I
believe.  In a sense, the IPv6 stack will not be aware at all about the
existence of CS, or of the fact there's point-to-point behind it.

In that case, I think it is very illustrative to picture a IEEE 802.16e
MAC header, followed by the Ethernet MAC header and followed by the IPv6
header.

In that case too, I think it should be useful to know (for implementer)
how the MAC addresses and type (of the intermediary Ether MAC header)
should contain.  And these addresses will be encoded - normally - in ND
messages.

>> I realize the 2-byte CID replaces what I commonly thought is a 
>> 6-byte IEEE MAC address.  If so, and only if no intermediary 802.3 
>> MAC header, then I think we should have a method to translate a 
>> 2-byte CID into an IID, and build an fe80 address out of that CID, 
>> no?
> 
> Actually, according to 802.16 spec, IP addresses is needed to 
> establish a connection and hence CID; to get the IP address the host 
> needs a connection, it's like deadlock.

Sounds so to me too.  It's good to point out in the draft that
802.16(e?) requires the host to have an IP address before establishing a
connection, which in turn will give it an address - and that't a
deadlock.  Maybe someone could provide the necessary solution to that
deadlock.

>  and authorization.

I see.  I think I can not comment on this, because I'm interested first
in IPv6 over 802.16e, then WiMax.

>> If there are multicast CIDs then we should map the IPv6 mc 
>> addresses into them too, no?
> 

Ok, if there are no multicast CIDs then it's probably useless to convert
Ethernet mc addresses (33:...) into them.

>>> Unspecified address if the host has not  configured the link 
>>> local address yet. This behavior should be same as RFC2461bis.
>> 
>> Ok.  Should the link-local address be auto-computed (such as cat 
>> IID to fe80)?  If so does the IID come from the BS?
> 
>  Local address configuration is same as that of Ethernet interface 
> type. One of the goals for the solution is to impose no changes to 
> the normal IPv6 host implementations, so it should work as defined in
>  RFC 2461/2462.

Which solution?  The CS design?  I think that should be done outside of
here, no?

Do we know what does look the MAC header offered by CS?

Alex

---

From: wenson <[email-masked]>
Date: Tue, 24 Oct 2006 21:27:33 +0800

Hi, Alex:
In section 5, it wrote:
>>The AR may be a function of the ASN-GW in the case of
>>   profiles A and C and is a function in the ASN in the case of profile
 >>  B. When the BS and the AR are separate entities and linked via the R6
 >>  interface, IPv6 packets between the BS and the AR are carried over a GRE tunnel.
 Since there are no R6 interface in profile B, do it mean that profile B is equivalent to the 802.16e deployment architecture with the integrated BS & AR? if in this case,why does the entity of ASN-GW is removed from WiMAX Network reference model in figure 2? why is there no R6 interface between BS and ASN-GW?

>>The transport connection over the air interface and
>>  the GRE tunnel between the BS and AR create a tunnel at the layer
>>   below IPv6.
In my view, the transport connection between MS and BS is one connection at the layer below IPv6, while the GRE tunnel between BS and AR is tunnel at the layer above IPv6. what do you think of it?

The transport connection between MS and BS and the GRE tunnel between BS and AR implement
point to point link between MS and AR.

Another point is that ipv6cs can implement point to point link, but it doesn't mean ipv6cs is limited to 
implement point to point link, it depends on the tunnel between BS and AR. what do you think of it?

Wenson

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 25 Oct 2006 08:40:52 +0000

Hi Alex,

> I believe each such connection would imply a different IP address, no?

May or many not be. Different connections are used for different QoS
requirements. There can be multiple IP addresses associated with a
single connection.

> address for all connections) then maybe not necessary to encode CID in ND.

As I mentioned above, there may not be a unique IP address per connection.

> max 4) they could be _all_ encoded in a 64bit IID.  Just a possibility.

No such restrictions either for now.

> should contain.  And these addresses will be encoded - normally - in ND

I hope these appears in IP over Ethernet CS draft. I think the draft
has been published from Max, I also need to look into this.

> deadlock.  Maybe someone could provide the necessary solution to that

But int the current PS draft, this is not a problem. May be because as
I mentioned
WIMAX NWG solved this by defining a initial service flow which will be
established as soon as the MS attaches to the network. This connection
does nto require an IP address.

> in IPv6 over 802.16e, then WiMax.

Currently most of the work is targeted at WiMAX Forum as there are no other
users atleast for now.

> Ethernet mc addresses (33:...) into them.

Yes. But 802.16 supports downlink multicast, that is not used.

> Which solution?  The CS design?  I think that should be done outside of

I was talking about IPv6 over XX CS drafts in 16ng. All of these solutions
should not be requiring any changes to the host side IP stack implementations.

> Do we know what does look the MAC header offered by CS?

The 802.16 MAC header does not differ by CS types. CS just
defines classification i.e. mapping higher layer PDUs to a particular CID.
If it is IP CS, it looks at IP and transport layers for mapping, if it
is Ethernet
CS it looks into Ethernet frame header in addition to IP and transport layer
headers.

Thanks,
Syam