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

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:
> 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.
> 
> 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 [email-masked] Tue Oct 17 10:38:59 2006
Date: Tue, 17 Oct 2006 09:16:16 +0900
From: "Soohong Daniel Park" <[email-masked]>
To: [email-masked]
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: [email-masked]

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.
>From [email-masked] Tue Oct 17 10:42:08 2006
Date: Tue, 17 Oct 2006 09:19:25 +0900
From: "Soohong Daniel Park" <[email-masked]>
To: [email-masked]
Subject: [16ng] WGLC : draft-ietf-16ng-ps-goals-00

Folks,

This is a two week WGLC on draft-ietf-16ng-ps-goals-00.

Please review the I-D and submit your comments to the authors or to
the list directly. The WGLC will exipre on October 31 (Pacific Time).

o I-D: http://www.ietf.org/internet-drafts/draft-ietf-16ng-ps-goals-00.txt

o Intended publication: Informational RFC

-- 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
>From [email-masked] Tue Oct 17 10:48:23 2006
Date: Tue, 17 Oct 2006 09:25:33 +0900
From: Myung-Ki Shin <[email-masked]>
Organization: ETRI
To: Soohong Daniel Park <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: [email-masked]
Reply-To: [email-masked]

Dainel,

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

Thanks,
Myung-Ki,

Soohong Daniel Park wrote:

> 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.
>

---

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 [email-masked] Tue Oct 17 19:36:14 2006
Date: Tue, 17 Oct 2006 11:07:09 +0200
From: Alexandru Petrescu <[email-masked]>
To: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: [email-masked]

Soininen Jonne (Nokia-NET/Espoo) wrote:
> Hi,
> 
> 
> On 10/16/06 11:34 PM, "ext Alexandru Petrescu" 
> <[email-masked]> wrote:
> 
> [snip]
>>> 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?
>> 
> 
> 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.

>>> 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.
> 
> 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 [email-masked] Tue Oct 17 21:02:49 2006
Date: Tue, 17 Oct 2006 13:35:15 +0300
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
From: "Soininen Jonne (Nokia-NET/Espoo)" <[email-masked]>
To: ext Alexandru Petrescu <[email-masked]>
cc: [email-masked]

Hi Alex,

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

> Soininen Jonne (Nokia-NET/Espoo) wrote:
>> Hi,
>> 
>> 
>> On 10/16/06 11:34 PM, "ext Alexandru Petrescu"
>> <[email-masked]> wrote:
>> 
>> [snip]
[snip] 
>> 
>> 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.

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.

> 
>> 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. 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.
> 
> 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.

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.

> 
>>>> 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.
>> 
>> 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?

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

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-

> 
>> How is that treated by the IP stack?
> 
> 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.

Cheers,

Jonne.

> Alex

-- 
Jonne Soininen
Nokia

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