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

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

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

On paper or in practice?

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

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

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
E-mail: [email-masked]

---

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 [email-masked] Tue Oct 17 23:53:38 2006
Date: Tue, 17 Oct 2006 15:30:28 +0200
From: Alexandru Petrescu <[email-masked]>
To: [email-masked]
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: [email-masked]
cc: [email-masked]

Jouni, thanks for the reply.

[email-masked] wrote:
> You might want to check e.f. 3GPP TS23.030 sub-clause 9.2.1.1. Though
>  it doesn't state there that the prefix is /64. Anyway the prefix
> must be unique within its scope to each PDP context. On the other
> hand 29.061 state that the interface identifier is 64bits (generated
> by GGSN) etc.. At least our (3GPP) networks are configured in this
> way.

How is this particular (3gpp) network configured?  Is it delivering one
prefix per mobile?  Is the mobile reachable from the IPv6 Internet?
Thanks!

>>  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.
> 
> Haven't seen this happening in practise.. Dunno if the asymmetry e.g.
>  in GPRS ul/dl timeslots numbers should reflect in any way to MTU 
> sizes.. I doubt not.

Probably yes timeslot-MTU relationship, I have no practical way to check.

Alex
>From [email-masked] Wed Oct 18 00:23:40 2006
Date: Tue, 17 Oct 2006 17:00:46 +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]>,
   <[email-masked]>
cc: [email-masked]

Alex,

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

>> 
>> Haven't seen this happening in practise.. Dunno if the asymmetry e.g.
>>  in GPRS ul/dl timeslots numbers should reflect in any way to MTU
>> sizes.. I doubt not.
> 
> Probably yes timeslot-MTU relationship, I have no practical way to check.

There should be no relationship with the MTU to the timeslots. The timeslots
are a "lower-layer" issue. The convergence sub-layer should hide these
things from IP.

How did you find this issue? I would also be really interested in, which
network this occurred. Please, feel free to contact me also off-list if you
don't feel like sharing this info with everybody for whatever reason.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34

---

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 [email-masked] Wed Oct 18 01:54:02 2006
Date: Tue, 17 Oct 2006 17:27:15 +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:
> Alex,
> 
> 
> On 10/17/06 5:29 PM, "ext Alexandru Petrescu"
>> The timeslot potential reason of MTU asymmetry was suggested by Jouni.
> 
> There is a remote possibility. However, this is not how GPRS was designed
> and implemented in the implementations I know...

Thanks, good to know.

>> How I found the MTU variance: have an IPv6 moving network behind an MR
>> connected to GPRS, and an IPv6 webserver on an LFN streaming MP3 towards
>> a client outside the UMTS network.  The MR sends IPv6-in-IPv6-in-IPv4 to
>> the UMTS network first-hop router.  MR's IPv4 stack receives
>> 'packet-too-big' from the first-hop router, so it fragments the IPv4
>> sent packet, to a size smaller than the size of packets it receives.
> 
> Again, your packet-too-big seems to come _after_ the packet has traveled
> over the GPRS network. Thus, the smaller MTU seems to be in the network
> _behind_ the first-hop-router. I don't know if the packets travel a
> different route to your client than coming down from the client.

YEs, those paths are things one never knows.

> If there would be a problem with the MTU of your GPRS link the packet would
> not even travel to the first-hop-router (it would not fit the link MTU and
> your MR would send a packet-too-big to your web server). You can check the
> MTU of your GPRS interface on the MR.
> 
> Anyways, you case does not show there is an MTU-asymmetric link, but that
> your packets are too big to a link in the network. It can easily happen as
> you have multiple layers of tunneling.

I'm not so sure about that.  Do you agree that usually the core network 
links have much larger MTU than edge wireless links?

>> In mobile WiMax or 802.16e - do we know whether the MS wireless link is
>> symmetric or asymmetric with respect to MTU?  Worth mentioning in the
>> draft?
> 
> It is symmetric. Anyways it does not matter. Every interface is set an MTU
> (Maximum Transmission Unit) - to my understanding you don't set the
> receiving side as the sending router/host is supposed to check that the
> packet fits to the limits of the layer 2.

The MTU parameter set on a linux interface is often irrelevant when 
receiving a packet too big message.

> Thus, I don't think this has to be mentioned - it generally isn't.

Ok.

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 [email-masked] Fri Oct 20 03:38:17 2006
Date: Thu, 19 Oct 2006 20:14:56 +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]

Alex,

On 10/19/06 6:31 PM, "ext Alexandru Petrescu"
<[email-masked]> wrote:
[snip]
> 
> 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. 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!)
> 
>>> 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?

No.

[snip] 

>>>> 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 :-)

I don't think so.

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

I mean privacy addresses such as RFC3041.

> 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 operators don't have a problem with giving /64 in 3GPP/3GPP2 networks
either.

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

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.

> 
> End users sometimes want privacy other times reachability.  Let this
> 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: 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 [email-masked] Sat Oct 21 03:16:05 2006
Date: Fri, 20 Oct 2006 22:22:06 +0530
From: "Syam Madanapalli" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>
Subject: Re: [16ng] WGLC: draft-ietf-16ng-ipv6-link-model-analysis-00 - REMIND
cc: [email-masked]

Hi,

> >>> We considered all of these deployment scenarios for both 802.16
> >>> and 802.16e. The current recommendation is to use Eth CS for the
> >>>  fixed/nomadic deployment scenarios,
> >>
> >> For fixed _or_ for nomadic?  For fixed _and_ for nomadic?  Fixed is
> >>  usually different than nomadic.
> >
> > OK, it is fixed and nomadic.
>
> Errr... so a mobile host would run same Ethernet CS layer as a fixed
> host, ok.

I do not understand this.
Anyways, if a mobile node supports Ethernet CS, it should be able to
connect to any BS that supports Ethernet CS, though the expectation
is that, the mobile hosts implement IP CS. On the other hand, portable
(e.g. laptops) and fixed device would implement Ethernet CS for
broadband connectivity.
[cut]
> >>> If not tunnel there should be other mechanisms that preserves the
> >>>  IP header till the packet reaches the AR.
> >>
> >> A router doesn't change the IP headers, right?  Neither does a
> >> bridge.
> >
> > Hop limit?
>
> Hop limit changes ok - and?  PAcket is still delivered, and no entity in
> the operator network cares about it other than decrementing it.  It's
> not like an address entry in the binding cache or in SA, SPD; nor a
> firewall ingress filtering...
>
> Why do you think decrementing the hop-limit in IP packet is bad for the
> MS-BS-AR network?

May be you have not come across the following draft on issues with
Multilink Subnet
http://www.ietf.org/internet-drafts/draft-iab-multilink-subnet-issues-00.txt

>
> >> An L3 tunnel is only needed if there is at least one intermediary
> >> router between BS and AR.  It's not pictured.
> >
> > The other reason we may need a tunnel between BS and AR is to
> > identify an MS when it sends a RS with unspecified address.
>
> Instead of the unspecified address why not using the fe80::IID, IID
> given by IPv6 LCP PPP AR to the MS?

RS can be sent even before the link local address is configured.
And right now no CS have been defined for PPP over 802.16.

>
> > There will be a tunnel [for] each MS between BS and AR.
>
> An IP-in-IP tunnel?  An IP-in-L2?  It implies it's not a 'tunnel', but
> normal inclusion of L3 messages in L2 messages.  You mean a 'connection'
> instead of 'tunnel'?
>
> (In TCP/IP terms a 'tunnel' is when one has two IP headers preceding the
> payload.  Logical extension to 'L2 tunnel' makes think of two L2 headers
> preceding the L3 datagram.)

It's two IP headers preceeding the payload.

Thanks,
Syam
>From [email-masked] Sat Oct 21 03:51:50 2006
Date: Fri, 20 Oct 2006 22:58:24 +0530
From: "Syam Madanapalli" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: "Soininen Jonne \(Nokia-NET/Espoo\)" <[email-masked]>
cc: [email-masked]

Some answers inline.

On 10/20/06, Alexandru Petrescu <[email-masked]> wrote:
> 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?

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

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

I think so.

>
> What is the value of the eventual type included in the layer 2 header
> 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
> 802.11 MAC addresses?

I think so.

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

Yes.

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

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

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

Thanks,
Syam

>
> > 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
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>
>From [email-masked] Sat Oct 21 04:57:05 2006
Date: Fri, 20 Oct 2006 20:28:43 +0200
From: Alexandru Petrescu <[email-masked]>
To: Syam Madanapalli <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: "Soininen Jonne \(Nokia-NET/Espoo\)" <[email-masked]>
cc: [email-masked]

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

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?
> 
> There is no such field in 02.16 MAC header.

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

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?

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

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?

>> 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.
> 
> It is same as Appendix A in RFC 4291 i.e. similar to Ethernet 
> interface.

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 [email-masked] Sat Oct 21 05:57:42 2006
Date: Sat, 21 Oct 2006 00:41:31 +0530
From: "Syam Madanapalli" <[email-masked]>
To: "Alexandru Petrescu" <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: "Soininen Jonne \(Nokia-NET/Espoo\)" <[email-masked]>
cc: [email-masked]

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.

On 10/20/06, Alexandru Petrescu <[email-masked]> wrote:
> 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?
> >
> > 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)
>
> Ok, and there seems to be a trailer too (checksum).  I believe the
> checksum is computed/verified by the link-layer implementation(?).

I also think so.

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

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

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

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

>
> >> What is the value of the eventual type included in the layer 2
> >> header when transporting IPv6?  Is it 0x86dd?
> >
> > There is no such field in 02.16 MAC header.
>
> 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?
> >
> > Yes.
>
> 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?

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
> into them too, no?

May be, but that use has not yet 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.
>
> Ok.  Should the link-local address be auto-computed (such as cat IID to
> 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
> dynamically negotiated?

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

>
> >> 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.
> >
> > It is same as Appendix A in RFC 4291 i.e. similar to Ethernet
> > interface.
>
> 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.

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

>
> Alex
>
>From [email-masked] Sat Oct 21 06:56:26 2006
Date: Fri, 20 Oct 2006 22:29:24 +0200
From: Alexandru Petrescu <[email-masked]>
To: Syam Madanapalli <[email-masked]>
Subject: Re: [16ng] Re: I-D ACTION:draft-ietf-16ng-ipv6-over-ipv6cs-00.txt
cc: "Soininen Jonne \(Nokia-NET/Espoo\)" <[email-masked]>
cc: [email-masked]

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.

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

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?
> 
> If Ethernet CS is being used then there will be Ethernet MAC header 
> between IP header and 802.16 MAC frame.

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.

> 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 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?
> 
> May be, but that use has not yet been defined.

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

>>>> 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.
>> 
>> Ok.  Should the link-local address be auto-computed (such as cat 
>> IID to 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.

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 [email-masked] Mon Oct 23 15:03:22 2006
From: "Hongseok Jeon" <[email-masked]>
To: <[email-masked]>
Date: Mon, 23 Oct 2006 13:39:27 +0900
Subject: [16ng] FW: 01 version ID-submission:
 draft-riegel-16ng-ip-over-eth-over-80216-01.txt

This is a multi-part message in MIME format.

------=_NextPart_000_015B_01C6F6A8.A8B2DA30
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_015C_01C6F6A8.A8B2DA30"

------=_NextPart_001_015C_01C6F6A8.A8B2DA30
Content-Type: text/plain;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

Hello folks,

Please find the attached I-D =
=A1=B0draft-riegel-16ng-ip-over-eth-over-80216-
01.txt=A1=B1.=20

The I-D describes behaviors for IPv4 and IPv6 packet transmission over
Ethernet CS over IEEE 802.16 network.=20

=20

Please review and provide comments.

=20

Thanks,=20

Hongseok=20

=20

  _____ =20

From: Hongseok Jeon [mailto:[email-masked]]=20
Sent: Monday, October 23, 2006 1:31 PM
To: [email-masked]'
Cc: Riegel, Maximilian; [email-masked]'
Subject: 01 version ID-submission: =
draft-riegel-16ng-ip-over-eth-over-80216-
01.txt

=20

Hello,=20

Here is a 01 version ID-submission:

draft-riegel-16ng-ip-over-eth-over-80216-01.txt

=20

Document title: Transmission of IP Packets over Ethernet over IEEE =
802.16

Authors: H. Jeon, M. Riegel, and S. Jeong

Abstract:

This document describes the behavior of the Ethernet emulation on top of
IEEE 802.16 to efficiently support the transmission of IPv4 as well as =
IPv6
packets over IEEE 802.16 radio links. Due to resource constraints of =
radio
transmission systems and the limitations of the IEEE 802.16 MAC layer =
for
the emulation of Ethernet, the transmission of IP over an emulated LAN =
on
top of IEEE 802.16 may considerably benefit by adding IP specific =
support
functions within the Ethernet emulation on top of IEEE 802.16.

=20

Thank you very much for your help

=20

Regards,

Hongseok

------=_NextPart_001_015C_01C6F6A8.A8B2DA30
Content-Type: text/html;
	charset="ks_c_5601-1987"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dks_c_5601-1987">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>

<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"time"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Dotum;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Gulim;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Dotum;
	panose-1:2 11 6 0 0 1 1 1 1 1;}
@font-face
	{font-family:Batang;
	panose-1:2 3 6 0 0 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	text-autospace:none;
	word-break:break-hangul;
	font-size:10.0pt;
	font-family:Batang;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:Gulim;
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Gulim;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:99.25pt 3.0cm 3.0cm 3.0cm;
	layout-grid:18.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DKO link=3Dblue vlink=3Dpurple>

<div class=3DSection1 style=3D'layout-grid:18.0pt'>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'>Hello =
folks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'>Please find the attached =
I-D =A1=B0</span></font><font
face=3D&#46027;&#50880;><span lang=3DEN-US =
style=3D'font-family:Dotum'>draft-riegel-16ng-ip-over-eth-over-80216-01.t=
xt=A1=B1</span></font><font
face=3D&#46027;&#50880;><span lang=3DEN-US style=3D'font-family:Dotum'>. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'>The I-D describes behaviors =
for IPv4
and IPv6 packet transmission over Ethernet CS over IEEE 802.16 network. =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'><o:p>&nbsp;</o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'>Please review and provide =
comments.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'><o:p>&nbsp;</o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'>Thanks, =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#46027;&#50880;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Dotum'>Hongseok =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy =
face=3D&#44404;&#47548;><span
lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Gulim;color:navy'><o:p>&nbsp;</o:p>=
</span></font></p>

<div>

<div class=3DMsoNormal align=3Dcenter =
style=3D'text-align:center;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt;font-family:"Times New Roman"'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</span></font></div>

<p class=3DMsoNormal align=3Dleft =
style=3D'text-align:left;text-autospace:ideograph-numeric =
ideograph-other;
word-break:keep-all'><b><font size=3D2 face=3DTahoma><span lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
face=3DTahoma><span lang=3DEN-US style=3D'font-family:Tahoma'> Hongseok =
Jeon
[mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, October 23, =
2006 <st1:time
o:ls=3D"trans" Hour=3D"13" Minute=3D"31" w:st=3D"on">1:31 =
PM</st1:time><br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
[email-masked]'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Riegel, Maximilian;
[email-masked]'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> 01 version =
ID-submission:
draft-riegel-16ng-ip-over-eth-over-80216-01.txt</span></font><font =
size=3D3
face=3D"Times New Roman"><span lang=3DEN-US =
style=3D'font-size:12.0pt;font-family:
"Times New Roman"'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal align=3Dleft style=3D'text-align:left'><font =
size=3D2 face=3D&#48148;&#53461;><span
lang=3DEN-US =
style=3D'font-size:10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Hello, =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Here is a 01 version =
ID-submission:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DNO-BOK
style=3D'font-size:10.0pt;font-family:Gulim'>draft-riegel-16ng-ip-over-et=
h-over-80216-01.txt<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DNO-BOK
style=3D'font-size:10.0pt;font-family:Gulim'><o:p>&nbsp;</o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Document title: =
Transmission of IP
Packets over Ethernet over IEEE 802.16<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Authors: H. Jeon, M. =
Riegel, and S.
Jeong<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Abstract:<o:p></o:p></span><=
/font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>This document describes the =
behavior
of the Ethernet emulation on top of IEEE 802.16 to efficiently support =
the
transmission of IPv4 as well as IPv6 packets over IEEE 802.16 radio =
links. Due
to resource constraints of radio transmission systems and the =
limitations of
the IEEE 802.16 MAC layer for the emulation of Ethernet, the =
transmission of IP
over an emulated LAN on top of IEEE 802.16 may considerably benefit by =
adding
IP specific support functions within the Ethernet emulation on top of =
IEEE
802.16.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'><o:p>&nbsp;</o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Thank you very much for =
your help<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'><o:p>&nbsp;</o:p></span></fo=
nt></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Regards,<o:p></o:p></span></=
font></p>

<p class=3DMsoNormal><font size=3D2 face=3D&#44404;&#47548;><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Gulim'>Hongseok<o:p></o:p></span></=
font></p>

</div>

</body>

</html>

------=_NextPart_001_015C_01C6F6A8.A8B2DA30--

------=_NextPart_000_015B_01C6F6A8.A8B2DA30
Content-Type: text/plain;
	name="draft-riegel-16ng-ip-over-eth-over-80216-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-riegel-16ng-ip-over-eth-over-80216-01.txt"

=0A=
=0A=
=0A=
Network Working Group                                            H. Jeon=0A=
Internet-Draft                                                      ETRI=0A=
Intended status: Standards Track                               M. Riegel=0A=
Expires: April 4, 2007                                           Siemens=0A=
                                                                S. Jeong=0A=
                                                                    ETRI=0A=
                                                                Oct 2006=0A=
=0A=
=0A=
       Transmission of IP Packets over Ethernet over IEEE 802.16=0A=
            draft-riegel-16ng-ip-over-eth-over-80216-01.txt=0A=
=0A=
Status of this Memo=0A=
=0A=
   By submitting this Internet-Draft, each author represents that any=0A=
   applicable patent or other IPR claims of which he or she is aware=0A=
   have been or will be disclosed, and any of which he or she becomes=0A=
   aware will be disclosed, in accordance with Section 6 of BCP 79.=0A=
=0A=
   Internet-Drafts are working documents of the Internet Engineering=0A=
   Task Force (IETF), its areas, and its working groups.  Note that=0A=
   other groups may also distribute working documents as Internet-=0A=
   Drafts.=0A=
=0A=
   Internet-Drafts are draft documents valid for a maximum of six months=0A=
   and may be updated, replaced, or obsoleted by other documents at any=0A=
   time.  It is inappropriate to use Internet-Drafts as reference=0A=
   material or to cite them other than as "work in progress."=0A=
=0A=
   The list of current Internet-Drafts can be accessed at=0A=
   http://www.ietf.org/ietf/1id-abstracts.txt.=0A=
=0A=
   The list of Internet-Draft Shadow Directories can be accessed at=0A=
   http://www.ietf.org/shadow.html.=0A=
=0A=
   This Internet-Draft will expire on April 4, 2007.=0A=
=0A=
Copyright Notice=0A=
=0A=
   Copyright (C) The Internet Society (2006).=0A=
=0A=
Abstract=0A=
=0A=
   This document describes the behavior of the Ethernet emulation on top=0A=
   of IEEE 802.16 to efficiently support the transmission of IPv4 as=0A=
   well as IPv6 packets over IEEE 802.16 radio links.  Due to resource=0A=
   constraints of radio transmission systems and the limitations of the=0A=
   IEEE 802.16 MAC layer for the emulation of Ethernet, the transmission=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 1]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
   of IP over an emulated LAN on top of IEEE 802.16 may considerably=0A=
   benefit by adding IP specific support functions within the Ethernet=0A=
   emulation on top of IEEE 802.16.=0A=
=0A=
=0A=
Table of Contents=0A=
=0A=
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3=0A=
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3=0A=
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3=0A=
   4.  The IEEE 802.16 Link Model . . . . . . . . . . . . . . . . . .  4=0A=
     4.1.  Connection Oriented Air Interface  . . . . . . . . . . . .  4=0A=
     4.2.  Convergence Sublayers  . . . . . . . . . . . . . . . . . .  4=0A=
     4.3.  Multicast and Broadcast Support in IEEE 802.16 . . . . . .  5=0A=
     4.4.  Solicitation of MAC addresses  . . . . . . . . . . . . . .  5=0A=
   5.  The IEEE 802.16 Network Model for Ethernet . . . . . . . . . .  5=0A=
     5.1.  IEEE 802.16 Ethernet Link Model  . . . . . . . . . . . . .  5=0A=
     5.2.  Ethernet without Native Broadcast and Multicast Support  .  6=0A=
     5.3.  Default Processing of Ethernet Frames  . . . . . . . . . .  6=0A=
   6.  Deployment Scenarios for IP over Ethernet over IEEE 802.16 . .  7=0A=
     6.1.  Public Access Scenario . . . . . . . . . . . . . . . . . .  7=0A=
     6.2.  VLAN Scenario  . . . . . . . . . . . . . . . . . . . . . .  8=0A=
   7.  Filtering and Forwarding . . . . . . . . . . . . . . . . . . .  8=0A=
     7.1.  IP Broadcast and Multicast Support . . . . . . . . . . . .  8=0A=
     7.2.  Packet Filtering . . . . . . . . . . . . . . . . . . . . .  8=0A=
     7.3.  Identification Cache Table . . . . . . . . . . . . . . . .  9=0A=
     7.4.  Address Resolution Protocol Proxy Function . . . . . . . . 10=0A=
     7.5.  Neighbor Discovery Relay Function  . . . . . . . . . . . . 10=0A=
     7.6.  Access Router Behavior . . . . . . . . . . . . . . . . . . 11=0A=
   8.  Transmission of IP over Ethernet . . . . . . . . . . . . . . . 11=0A=
     8.1.  IPv4 over Ethernet . . . . . . . . . . . . . . . . . . . . 11=0A=
       8.1.1.  Address Resolution . . . . . . . . . . . . . . . . . . 12=0A=
     8.2.  IPv6 over Ethernet . . . . . . . . . . . . . . . . . . . . 12=0A=
       8.2.1.  Router Discovery, Prefix Discovery and Parameter=0A=
               Discovery  . . . . . . . . . . . . . . . . . . . . . . 12=0A=
       8.2.2.  Address Configuration  . . . . . . . . . . . . . . . . 13=0A=
       8.2.3.  Address Resolution . . . . . . . . . . . . . . . . . . 13=0A=
     8.3.  Maximum Transmission Unit Consideration  . . . . . . . . . 13=0A=
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13=0A=
   10. Informative References . . . . . . . . . . . . . . . . . . . . 13=0A=
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15=0A=
   Intellectual Property and Copyright Statements . . . . . . . . . . 16=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 2]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
1.  Introduction=0A=
=0A=
   IEEE 802.16 [IEEE802.16] defines a point-to-multipoint radio=0A=
   transmission system connecting a Base Station (BS) with multiple=0A=
   Subscriber Stations (SSs).  IEEE 802.16e [IEEE802.16e] amends the=0A=
   base specification with PHY and MAC functions for supporting mobile=0A=
   terminals by adopting the same data link principles also for mobile=0A=
   networking systems.=0A=
=0A=
   This document provides a detailed description of the Ethernet=0A=
   emulation on top of IEEE 802.16 with additional functionalities for=0A=
   efficient support of IPv4 packets as well as IPv6 packets.=0A=
=0A=
=0A=
2.  Requirements=0A=
=0A=
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A=
   document are to be interpreted as described in [RFC2119].=0A=
=0A=
=0A=
3.  Terminology=0A=
=0A=
   Description of following some terms is taken directly from=0A=
   [IEEE802.16] and [IEEE802.16e].=0A=
=0A=
   Base Station (BS):  A generalized equipment set providing=0A=
      connectivity, management, and control of the subscriber station.=0A=
=0A=
   Subscriber Station (SS):  A generalized equipment set providing=0A=
      connectivity between subscriber equipment and a base station.=0A=
      Within this document the term SS also represents the Mobile=0A=
      Subscriber Station introduced in IEEE 802.16e=0A=
=0A=
   Service-specific Convergence Sublayer (CS):  Sublayer in IEEE 802.16=0A=
      MAC layer which classifier external network data and associates=0A=
      them to the proper MAC service flow identifier and connection=0A=
      identifier.=0A=
=0A=
   Connection Identifier (CID):  A 16 bit value that identifies a=0A=
      connection to equivalent peers in the MAC of the base station and=0A=
      subscriber station.=0A=
=0A=
   Source Node:  Host which initiates an IPv6 Neighbor Discovery message=0A=
      using its own unique MAC address.  A Source Node may be co-located=0A=
      with a SS or may be behind a SS, when the SS acts as a bridge.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 3]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
   Target Node:  Host which is addressed by the target field in an IPv6=0A=
      Neighbor Discovery message.  The Target Node has its own unique=0A=
      MAC address and may be co-located with a SS or may be behind a SS,=0A=
      when the SS acts as a bridge=0A=
=0A=
=0A=
4.  The IEEE 802.16 Link Model=0A=
=0A=
4.1.  Connection Oriented Air Interface=0A=
=0A=
   The IEEE 802.16 MAC provides connections between the BS and its=0A=
   associated SSs.  Each of these connections is identified by a 16 bit=0A=
   CID number and has defined QoS capabilities.  Multiple connections=0A=
   can be established between a BS and a SS, each with its particular=0A=
   QoS class and direction.=0A=
=0A=
              |         |         |                 |=0A=
           +--+--+   +--+--+   +--+--+         +--+-+-+--+=0A=
           | MAC |   | MAC |   | MAC |         |   MAC   |=0A=
           +-----+   +-----+   +-----+         +---------+=0A=
           | PHY |   | PHY |   | PHY |         |   PHY   |=0A=
           +-+-+-+   +-+-+-+   +-+-+-+         +-+-+-+-+-+=0A=
             | |       | |       | |             | | | |=0A=
             | +-------|-+-------|-+----CID#w----+ | | |=0A=
             |         |         +------CID#x------+ | |=0A=
             |         +----------------CID#y--------+ |=0A=
             +--------------------------CID#z----------+=0A=
             SS#1      SS#2      SS#3              BS=0A=
=0A=
                  Figure 1. Basic IEEE 802.16 Link Model=0A=
=0A=
   While uplink connections provide only unicast transmission=0A=
   capabilities from a particular SS to the BS, downlink connections can=0A=
   be used for unicast transmission from the BS to a particular SS as=0A=
   well as for multicast transmissions to a group of SSs.=0A=
=0A=
4.2.  Convergence Sublayers=0A=
=0A=
   The assignment of higher layer packets to particular service flows=0A=
   and the related CIDs is performed within the IEEE 802.16 convergence=0A=
   sublayer by classifying the packets according to particular header=0A=
   fields.  To enable the transmission of different kind of payloads=0A=
   over IEEE 802.16, multiple types of classification types are defined,=0A=
   each specific for one kind of upper layer protocol, like Ethernet,=0A=
   IPv4, IPv6 or even for encapsulated payload, like IPv4 over Ethernet=0A=
   or IPv6 over Ethernet.=0A=
=0A=
   Optionally the convergence sublayer performs a packet header=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 4]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
   suppression reducing static parts of the header to a single byte=0A=
   value.  With the application of the packet header suppression=0A=
   function there is mostly no difference in header overhead over the=0A=
   air for Ethernet encapsulated IP packets in comparison to plain IP=0A=
   packets.=0A=
=0A=
4.3.  Multicast and Broadcast Support in IEEE 802.16=0A=
=0A=
   Downlink connections can be shared among multiple SSs, enabling=0A=
   multicast channels with multiple SSs receiving the same information=0A=
   from the BS.  Multicast is not enabled in the uplink but must be=0A=
   realized by an entity on top the IEEE 802.16 MAC sending packets=0A=
   received on a unicast uplink downstream on a multicast channel.=0A=
=0A=
4.4.  Solicitation of MAC addresses=0A=
=0A=
   The 48-bit unique MAC address of a SS is used during the initial=0A=
   ranging process for the identification of a SS and verified by the=0A=
   succeeding PKMv2 authentication phase.  As a result, the BS=0A=
   establishes a list of solicited-node MAC addresses of all SSs=0A=
   connected to the BS.  Note that there may be additional MAC addresses=0A=
   behind SSs when SSs act as bridge connecting networks behind the SSs.=0A=
   The additional MAC addresses may be also solicited when there is a=0A=
   controlled link state for the hosts behind the SS and the SS performs=0A=
   authentication of the link, e.g. by running IEEE 802.1X on the SS.=0A=
=0A=
=0A=
5.  The IEEE 802.16 Network Model for Ethernet=0A=
=0A=
5.1.  IEEE 802.16 Ethernet Link Model=0A=
=0A=
   According to [I-D.ietf-ipv6-2461bis], an IP Link is defined as a=0A=
   communication facility or medium over which nodes can communicate at=0A=
   the link layer, i.e. the layer immediately below IP.  IEEE 802.16=0A=
   provides point-to-point connections between SSs and the BS without=0A=
   enabling any direct SS to SS connectivity.  Ethernet is realized on=0A=
   top of IEEE 802.16 by implementing bridging between all SSs with IEEE=0A=
   802.16 providing the links between the hosts and the bridge behind=0A=
   the BS like the twisted pair wires used in today's switched Ethernet.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 5]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
          ------------------------ IP Link ------------------------=0A=
=0A=
          |         |                 |                 |         |=0A=
         ETH       ETH               ETH               ETH       ETH=0A=
          |         |                 |                 |         |=0A=
          |         |       +---------+---------+       |         |=0A=
          |         |       |      Bridge       |       |         |=0A=
          |         |       +--+-+---------+-+--+       |         |=0A=
          |         |          | |         | |          |         |=0A=
       +--+--+   +--+--+    +--+-+--+   +--+-+--+    +--+--+   +--+--+=0A=
       | MAC |   | MAC |    |  MAC  +   +  MAC  |    | MAC |   | MAC |=0A=
       +-----+   +-----+    +-------+   +-------+    +-----+   +-----+=0A=
       | PHY |   | PHY |    |  PHY  +   +  PHY  |    | PHY |   | PHY |=0A=
       +-+-+-+   +-+-+-+    +-+-+-+-+   +-+-+-+-+    +-+-+-+   +-+-+-+=0A=
         | |       | |        | | |       | | |        | |       | |=0A=
         | +-------|-+--CID#u-+ | |       | | +-CID#x--+-|-------+ |=0A=
         |         +----CID#v---+ |       | +---CID#y----+         |=0A=
         +--------------CID#w-----+       +-----CID#z--------------+=0A=
=0A=
         SS#1      SS#2       BS#1         BS#2       SS#3      SS#4=0A=
=0A=
             Figure 2. IEEE 802.16 IP over Ethernet Link Model=0A=
=0A=
   It is possible to control the size and coverage of IP links by=0A=
   segmenting the Ethernet and grouping particular links into VLANs.=0A=
   Such segmentation is mostly done between BSs, but it is also possible=0A=
   to extend the segmentation over IEEE802.16 links when multiple hosts=0A=
   are attached to a bridge at the SS.=0A=
=0A=
5.2.  Ethernet without Native Broadcast and Multicast Support=0A=
=0A=
   Ethernet is emulated on top of IEEE 802.16 without making use of MBS=0A=
   as defined in 6.3.23 of [IEEE802.16e] to allow full control over the=0A=
   reaction of SSs to broadcast messages.  Instead of using MBS,=0A=
   broadcast and multicast messages are transferred in a unicast manner.=0A=
=0A=
5.3.  Default Processing of Ethernet Frames=0A=
=0A=
   If the SS performs a bridging function then it SHALL support Standard=0A=
   Learned Bridging between all its LAN ports and the airlink.  The BS=0A=
   SHALL forward all the radio connections belonging to one SS to a port=0A=
   of a bridge performing Standard Learned Bridging between all ports on=0A=
   the radio side and the interfaces towards the network side.=0A=
=0A=
   When performing Standard Learned Bridging, the SS, when acting as a=0A=
   bridge, or the bridge behind the BSs shall learn all source MAC=0A=
   addresses originating from a port resulting in Dynamic Filtering=0A=
   Entries if the same MAC addresses are not already listed as Static=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 6]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
   Filtering Entries.  The accumulation of all learned MAC to port=0A=
   associations and all Static Filtering Entries derived from solicited-=0A=
   node MAC addresses constitute the Filtering Database.  The Standard=0A=
   Learned Bridge shall automatically unlearn a Dynamic Filtering Entry=0A=
   MAC to port relationship after BRIDGETIMEOUT seconds have expired=0A=
   without any traffic from that MAC address.=0A=
=0A=
   When performing bridging, any packets destined for one of the=0A=
   addresses in the Filtering Database SHALL be forwarded directly to=0A=
   that port and all packets received from a port, for which the=0A=
   packet's destination MAC address is also an entry for that port in=0A=
   the Filtering Database, SHALL be silently discarded.=0A=
=0A=
=0A=
6.  Deployment Scenarios for IP over Ethernet over IEEE 802.16=0A=
=0A=
   Figure 3 and 4 show possible deployment scenarios in case of IP over=0A=
   Ethernet over IEEE 802.16.  In both figures, the AR is connected to a=0A=
   bridge, which is connected to all BSs.  The bridge supports Static=0A=
   Filtering Entries and Standard Learned Bridging, as specified in=0A=
   Section 5.3.  Multiple ARs can exist on a link, and a subnet (IP=0A=
   Link) consists of multiple hosts usually being co-located with a SS=0A=
   acting as bridge.  The network behind a SS can support various access=0A=
   network technologies, e.g. 802.3, 802.11 or 802.15.=0A=
=0A=
6.1.  Public Access Scenario=0A=
=0A=
   Figure 3 depicts an IEEE 802.16 network deployment scenario without=0A=
   direct host-to-host communication.  In the general public access=0A=
   case, direct communication between nodes is restricted because of=0A=
   security and accounting issues.  In this scenario, the bridge SHALL=0A=
   forward all packets received from any radio side port to a network=0A=
   side port.  Peer-to-peer communication is not supported by the bridge=0A=
   and all packets originated from a SS should be delivered to an AR.=0A=
=0A=
=0A=
               +-----+    +-----+      +-------+=0A=
               | SS  |----| BS1 |------|       |       +------+=0A=
               +-----+    +-----+      |       |-------|  AR  |=0A=
                                       |Bridge |       +------+=0A=
      +-----+  +-----+    +-----+      |       |=0A=
      |Hosts|--| SS  |----| BS2 |------|       |=0A=
      +-----+  +-----+    +-----+      +-------+=0A=
      This network=0A=
      may exist behind SS=0A=
=0A=
=0A=
     Figure 3. Network Model without direct host-to-host communication=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 7]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
6.2.  VLAN Scenario=0A=
=0A=
   Figure 4 shows the VLAN scenario.  Particular SSs grouped into a VLAN=0A=
   can directly communicate with each other when this mode is enabled=0A=
   for the VLAN.  Otherwise, direct communication is prohibited and the=0A=
   VLAN shows the same behavior as the public access scenario case.  The=0A=
   bridge has been extended to support VLAN capability and configurable=0A=
   direct host-to-host communication.=0A=
=0A=
=0A=
               +-----+    +-----+      +-------+=0A=
               | SS  |----| BS1 |------|       |       +------+=0A=
               +-----+    +-----+      |Bridge |-------|  AR  |=0A=
                                       |(VLAN) |       +------+=0A=
      +-----+  +-----+    +-----+      |       |=0A=
      |Hosts|--| SS  |----| BS2 |------|       |=0A=
      +-----+  +-----+    +-----+      +-------+=0A=
      This network=0A=
      may exist behind SS=0A=
=0A=
=0A=
      Figure 4. Network Model with direct host-to-host communication=0A=
=0A=
=0A=
7.  Filtering and Forwarding=0A=
=0A=
7.1.  IP Broadcast and Multicast Support=0A=
=0A=
   As explained in 5.2, no native MBS support is used for emulation of=0A=
   the Ethernet behavior over IEEE 802.16 links.  Only point-to-point=0A=
   connections are established between SSs and BS.  Multiple connections=0A=
   belonging to the same SS are feeded into a single bridge port.=0A=
   Broadcast or all-nodes multicast data such as router advertisements=0A=
   are unicasted to intended SS via the point-to-point connection.=0A=
=0A=
7.2.  Packet Filtering=0A=
=0A=
   The bridge SHALL have the ability to enable or disable any filtering=0A=
   functionality defined herein.  If a packet is filtered it SHALL be=0A=
   silently discarded.  The filtering functionality is based on the=0A=
   information of the Identification Cache Table (ICT), which is an=0A=
   extension of the Filtering Database.  Details of the ICT are given in=0A=
   Section 7.3.=0A=
=0A=
   The bridge SHALL support filtering of all packets received from a=0A=
   network side port to a destination MAC address not existing in the=0A=
   ICT.=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 8]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
   The bridge SHALL support filtering of all packets received from a=0A=
   network side port to a broadcast or multicast MAC address.=0A=
=0A=
   If filtering is enabled the bridge SHALL permit all Address=0A=
   Resolution Protocol messages to pass to the ARP Proxy Agent and all=0A=
   Neighbor Discovery messages to pass to the Neighbor Discovery (ND)=0A=
   Relay Agent, as specified in following section.=0A=
=0A=
   All multicast and multicast control messages are forwarded according=0A=
   to [RFC4541]=0A=
=0A=
7.3.  Identification Cache Table=0A=
=0A=
   The bridge establishes and maintains information about each SS by the=0A=
   mean of an Identification Cache Table (ICT).=0A=
=0A=
   For IPv4 over Ethernet, the ICT contains for each MAC address, the=0A=
   lifetime if it is not Static Filtering Entry and one or more IPv4=0A=
   addresses.=0A=
=0A=
   For IPv6 over Ethernet, the ICT contains for each MAC address, the=0A=
   lifetime if it is not Static Filtering Entry, the link-local address=0A=
   and one or more IPv6 addresses with associated Valid Flags.=0A=
=0A=
   The ARP Proxy Agent and the ND Relay Agent functions are based on=0A=
   information contained in the ICT.=0A=
=0A=
   IPv4 addresses can be learned by examining the source address of=0A=
   packets or DHCP Response message.=0A=
=0A=
   IPv6 link-local addresses can be derived from solicited-node MAC=0A=
   address.  Note that Privacy Extension for IPv6 address [RFC3041] is=0A=
   not considered in the current version.=0A=
=0A=
   The IPv6 address is learned by extracting the Target field in the=0A=
   Neighbor Solicitation (NS) message for Duplicate Address Detection=0A=
   (DAD), if the tentative IPv6 address does not exist yet as a valid=0A=
   IPv6 address in the ICT.  In this case, the Valid Flag is set to=0A=
   indicate the tentative IPv6 address has become valid.  Otherwise, the=0A=
   IPv6 address in the Target field in a DAD NS message is stored as=0A=
   IPv6 address with Valid Flag is not set to identify the Source Node=0A=
   when the bridge relays the Neighbor Advertisement message from Target=0A=
   Node.=0A=
=0A=
   The lifetime of each entry follows the lifetime of the Learned Bridge=0A=
   Table.  Figure 5 and Figure 6 show the ICT for IPv4 over Ethernet and=0A=
   IPv6 over Ethernet.=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                 [Page 9]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
             +---------+----------+------+-------+--~--+--------+=0A=
             |   MAC   |  Port #  | Life | IPv4  |     |  IPv4  |=0A=
             | address |          | time |address|     | address|=0A=
             +---------+----------+------+-------+--~--+--------+=0A=
             |         |          |      |       | ... |        |=0A=
             +---------+----------+------+-------+--~--+--------+=0A=
=0A=
=0A=
           Figure 5. ICT on Bridge in case of IPv4 over Ethernet=0A=
=0A=
=0A=
=0A=
     +----+-----+----+----------+----------+----+-----+--~--+----+-----+=0A=
     |MAC |Port#|Life|Solicited-|Link-local|IPv6|Valid|     |IPv6|Valid|=0A=
     |addr|     |time|node addr |   addr   |addr|Flag |     |addr|Flag |=0A=
     +----+-----+----+----------+----------+----+-----+--~--+----+-----+=0A=
     |    |     |    |          |          |    |     | ... |    |     |=0A=
     +----+-----+----+----------+----------+----+-----+--~--+----+-----+=0A=
=0A=
=0A=
           Figure 6. ICT on Bridge in case of IPv6 over Ethernet=0A=
=0A=
7.4.  Address Resolution Protocol Proxy Function=0A=
=0A=
   In the case of IPv4 over Ethernet, ARP requests can be responded by=0A=
   the ARP Proxy Agent of the bridge. (refer to Section 8.1.1 for more=0A=
   detail)=0A=
=0A=
   However, a proxy function in IPv6 over Ethernet is subjected to=0A=
   restriction because of security issues.  Support of SeND [RFC3971]=0A=
   has been adopted in the IPv6 over Ethernet case.=0A=
=0A=
7.5.  Neighbor Discovery Relay Function=0A=
=0A=
   In the case of IPv6 over Ethernet, the AR sends periodically Router=0A=
   Advertisement and the Router Advertisement messages can be relayed by=0A=
   the ND Relay Agent of the bridge.  The ND Relay Agent unicasts the=0A=
   Router Advertisement via all the already established a point-to-point=0A=
   connections between SSs and bridge.=0A=
=0A=
   Note that the relaying of Router Advertisement MUST NOT affect=0A=
   validness of SeND Timestamp.=0A=
=0A=
   When the bridge receives Neighbor Solicitation for DAD, the ND Relay=0A=
   Agent of the bridge performs the same operation as the Relay DAD.=0A=
   The ND Relay Agent looks up in the ICT to detect whether a tentative=0A=
   address in the Neighbor Solicitation message is in use or not.  If=0A=
   the tentative address is not in use, the ND Relay Agent discards the=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                [Page 10]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
   Neighbor Solicitation.  Otherwise, the Neighbor Solicitation message=0A=
   is relayed only to the addressed Target Node.=0A=
=0A=
   When the bridge receives the DAD Neighbor Advertisement message from=0A=
   the Target Node, the ND Relay Agent of the bridge identifies the=0A=
   corresponding Source Node by the ICT and then unicasts the DAD=0A=
   Neighbor Advertisement message via the established point-to-point=0A=
   connection to the corresponding Source Node.=0A=
=0A=
7.6.  Access Router Behavior=0A=
=0A=
   The assignment of a common prefix to all SSs means locating them "on-=0A=
   link" in terms of IP packet transfer.  According to=0A=
   [I-D.ietf-ipv6-2461bis], an IP node performs a longest prefix match=0A=
   against the prefix list in order to decide whether the destination of=0A=
   the IP packet is on-link or not.  Therefore, SSs sharing a prefix can=0A=
   be said to be on-link IP nodes.=0A=
=0A=
   In the Public Access scenario, all unicast packets originated from a=0A=
   SS should be delivered to an AR even though the SS sends packets to=0A=
   on-link SSs.  Therefore, it is necessary for the AR to relay the on-=0A=
   link packets.=0A=
=0A=
   The AR SHALL have packet-relay functionality.  The AR relays packets=0A=
   destined for IP broadcast address and link-local scoped multicast=0A=
   addresses to incoming interface again.=0A=
=0A=
   When the AR relays packets destined for ab on-link host, the packet=0A=
   may be forwarded onto the incoming interface.  It should be prevented=0A=
   that the AR transmits a Redirect message to sender when direct=0A=
   communication between on-link SSs occurs.=0A=
=0A=
   In the case of the VLAN scenario, direct communication between SSs=0A=
   may be enabled for all SSs belonging to a particular VLAN.  In this=0A=
   case, no special handling is required.=0A=
=0A=
=0A=
8.  Transmission of IP over Ethernet=0A=
=0A=
8.1.  IPv4 over Ethernet=0A=
=0A=
   [RFC0894] defines the transmission of IP packets over Ethernet=0A=
   networks.  It contains the specification of the encapsulation of the=0A=
   IP packets into Ethernet frames as well as rules for mapping of IP=0A=
   addresses onto Ethernet MAC addresses.  The use of ARP [RFC0826] is=0A=
   recommended for dynamic address resolution.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                [Page 11]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
8.1.1.  Address Resolution=0A=
=0A=
   The bridge SHALL support an ARP Proxy.  The bridge SHALL have the=0A=
   ability to enable or disable the ARP Proxy.=0A=
=0A=
   If the ARP Proxy is disabled, the ARP Proxy Agent shall pass all ARP=0A=
   packets without discrimination or modification using bridging.  The=0A=
   ARP Proxy Agent shall pass all ARP Response packets without=0A=
   discrimination or modification using bridging.=0A=
=0A=
   If the ARP Proxy is enabled, upon receiving an ARP Request from an=0A=
   radio side interface, the ARP Proxy Agent shall unicast an ARP=0A=
   Response back to the interface provided that the target address=0A=
   matches an entry in the ICT.  Otherwise, the ARP Proxy Agent shall=0A=
   flood the ARP Request to all network side interfaces.=0A=
=0A=
   The ARP Proxy Agent shall silently discard any received self-ARP=0A=
   Requests.  Those are requests for a target IP address, that when=0A=
   queried in the ICT results in a response MAC equal to the Request's=0A=
   source MAC address.=0A=
=0A=
   The ARP Proxy Agent shall issue a gratuitous ARP on the network side=0A=
   interfaces for any new addition to the ICT.  An unsolicited broadcast=0A=
   ARP Response constitutes a gratuitous ARP.=0A=
=0A=
8.2.  IPv6 over Ethernet=0A=
=0A=
   The transmission of IPv6 Packets over Ethernet Networks is defined by=0A=
   [RFC2464] providing the frame format for encapsulation of IPv6=0A=
   packets into Ethernet frames as well as the methods of forming IPv6=0A=
   link-local addresses and statelessly autoconfigured addresses on=0A=
   Ethernet networks.=0A=
=0A=
8.2.1.  Router Discovery, Prefix Discovery and Parameter Discovery=0A=
=0A=
   Router Discovery, Prefix Discovery and Parameter Discovery procedures=0A=
   are achieved by receiving Router Advertisement (RA) messages.  The RA=0A=
   is forwarded by using all-nodes IP multicast transmission.=0A=
=0A=
   This document assumes a point-to-point connection between each SS and=0A=
   bridge.  The ND Relay Agent of the bridge unicast the RA from AR via=0A=
   the point-to-point connection.=0A=
=0A=
   Note that the RA has a long lifetime and minimum packet size which=0A=
   can be sent in IEEE 802.16 to the SSs being in sleep-mode during the=0A=
   periodic wakeup-time.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                [Page 12]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
8.2.2.  Address Configuration=0A=
=0A=
8.2.2.1.  Stateful Address Autoconfiguration=0A=
=0A=
   When the'M' flag in the received RA is set, a SS should perform=0A=
   stateful address configuration according to [RFC3315].  In this case,=0A=
   an AR supports DHCPv6 server or relay function.=0A=
=0A=
8.2.2.2.  Stateless Address Autoconfiguration=0A=
=0A=
   The global IPv6 addresses is derived based on prefix and EUI-64-=0A=
   derived interface identifier and then confirmed through Duplicate=0A=
   Address Detection (DAD) as specified in [RFC2462].=0A=
=0A=
   For DAD, the Source Node sends Neighbor Solicitation to the=0A=
   solicited-node MAC address corresponding to the generated global IPv6=0A=
   address for DAD.  The Neighbor Solicitation is passed to the ND Relay=0A=
   Agent when arriving at the bridge.=0A=
=0A=
8.2.3.  Address Resolution=0A=
=0A=
   The Source Node sends Neighbor Solicitation to the solicited-node=0A=
   address corresponding to the target address for address resolution.=0A=
=0A=
   Upon receiving the Neighbor Solicitation, the bridge retrieves the=0A=
   port corresponding to the solicited-node MAC address in its ICT and=0A=
   then forwards the Neighbor Solicitation via that port.=0A=
=0A=
   Finally the Target Node responds to the Neighbor Solicitation.=0A=
=0A=
8.3.  Maximum Transmission Unit Consideration=0A=
=0A=
   When stacked VLAN headers are transferred over GRE tunnels, the sizes=0A=
   of the VLAN headers and the GRE header need to be considered in=0A=
   setting the value of MTU of the transport path.=0A=
=0A=
=0A=
9.  Security Considerations=0A=
=0A=
   [RFC3971] specifies security mechanisms for ND Protocol and defines=0A=
   means for securing ND Protocol messages.  This document aims to fully=0A=
   support security mechanisms specified in [RFC3971].=0A=
=0A=
=0A=
10.  Informative References=0A=
=0A=
   [I-D.ietf-ipv6-2461bis]=0A=
              Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                [Page 13]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
              draft-ietf-ipv6-2461bis-08 (work in progress),=0A=
              September 2006.=0A=
=0A=
   [I-D.ietf-16ng-ps-goals]=0A=
              Jee, J., "IP over 802.16 Problem Statements and Goals",=0A=
              draft-ietf-16ng-ps-goals-00 (work in progress),=0A=
              February 2006.=0A=
=0A=
   [IEEE802.16]=0A=
              IEEE Std 802.16-2004, "IEEE Standard for Local and=0A=
              metropolitan area networks,  Part 16: Air Interface for=0A=
              Fixed Broadband Wireless Access Systems", October 2004.=0A=
=0A=
   [IEEE802.16e]=0A=
              IEEE P802.16e-2005, "IEEE Standard for Local and=0A=
              metropolitan area networks, Amendment for Physical and=0A=
              Medium Access  Control Layers for Combined Fixed and=0A=
              Mobile Operation in Licensed Bands", December 2005.=0A=
=0A=
   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or=0A=
              converting network protocol addresses to 48.bit Ethernet=0A=
              address for transmission on Ethernet hardware", STD 37,=0A=
              RFC 826, November 1982.=0A=
=0A=
   [RFC0894]  Hornig, C., "Standard for the transmission of IP datagrams=0A=
              over Ethernet networks", STD 41, RFC 894, April 1984.=0A=
=0A=
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate=0A=
              Requirement Levels", BCP 14, RFC 2119, March 1997.=0A=
=0A=
   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6=0A=
              (IPv6) Specification", RFC 2460, December 1998.=0A=
=0A=
   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor=0A=
              Discovery for IP Version 6 (IPv6)", RFC 2461,=0A=
              December 1998.=0A=
=0A=
   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet=0A=
              Networks", RFC 2464, December 1998.=0A=
=0A=
   [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for=0A=
              Stateless Address Autoconfiguration in IPv6", RFC 3041,=0A=
              January 2001.=0A=
=0A=
   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure=0A=
              Neighbor Discovery (SEND)", RFC 3971, March 2005.=0A=
=0A=
   [RFC4541]  Christensen, M., Kimball, K., and F. Solensky,=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                [Page 14]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
              "Considerations for Internet Group Management Protocol=0A=
              (IGMP) and Multicast Listener Discovery (MLD) Snooping=0A=
              Switches", RFC 4541, May 2006.=0A=
=0A=
=0A=
Authors' Addresses=0A=
=0A=
   Hongseok Jeon=0A=
   Electronics Telecommunications Research Institute=0A=
   161 Gajeong-dong, Yuseong-gu=0A=
   Daejeon,   305-350=0A=
   KOREA=0A=
=0A=
   Phone: +82-42-860-3892=0A=
   Email: [email-masked]=0A=
=0A=
=0A=
   Max Riegel=0A=
   Siemens=0A=
   St-Martin-Str 76=0A=
   Munich,   81541=0A=
   Germany=0A=
=0A=
   Phone: +49-89-636-75194=0A=
   Email: [email-masked]=0A=
=0A=
=0A=
   Sangjin Jeong=0A=
   Electronics Telecommunications Research Institute=0A=
   161 Gajeong-dong, Yuseong-gu=0A=
   Daejeon,   305-350=0A=
   KOREA=0A=
=0A=
   Phone: +82-42-860-1877=0A=
   Email: [email-masked]=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                [Page 15]=0A=
=0C=0A=
Internet-Draft           IPoEth over IEEE 802.16                Oct 2006=0A=
=0A=
=0A=
Full Copyright Statement=0A=
=0A=
   Copyright (C) The Internet Society (2006).=0A=
=0A=
   This document is subject to the rights, licenses and restrictions=0A=
   contained in BCP 78, and except as set forth therein, the authors=0A=
   retain all their rights.=0A=
=0A=
   This document and the information contained herein are provided on an=0A=
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A=
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=0A=
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=0A=
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=0A=
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A=
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A=
=0A=
=0A=
Intellectual Property=0A=
=0A=
   The IETF takes no position regarding the validity or scope of any=0A=
   Intellectual Property Rights or other rights that might be claimed to=0A=
   pertain to the implementation or use of the technology described in=0A=
   this document or the extent to which any license under such rights=0A=
   might or might not be available; nor does it represent that it has=0A=
   made any independent effort to identify any such rights.  Information=0A=
   on the procedures with respect to rights in RFC documents can be=0A=
   found in BCP 78 and BCP 79.=0A=
=0A=
   Copies of IPR disclosures made to the IETF Secretariat and any=0A=
   assurances of licenses to be made available, or the result of an=0A=
   attempt made to obtain a general license or permission for the use of=0A=
   such proprietary rights by implementers or users of this=0A=
   specification can be obtained from the IETF on-line IPR repository at=0A=
   http://www.ietf.org/ipr.=0A=
=0A=
   The IETF invites any interested party to bring to its attention any=0A=
   copyrights, patents or patent applications, or other proprietary=0A=
   rights that may cover technology that may be required to implement=0A=
   this standard.  Please address the information to the IETF at=0A=
   [email-masked].=0A=
=0A=
=0A=
Acknowledgment=0A=
=0A=
   Funding for the RFC Editor function is provided by the IETF=0A=
   Administrative Support Activity (IASA).=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Jeon, et al.              Expires April 4, 2007                [Page 16]=0A=
=0C=0A=
=0A=

------=_NextPart_000_015B_01C6F6A8.A8B2DA30--