Subject: [16ng] test

From: Soohong Daniel Park <[email-masked]>
Date: Mon, 12 Sep 2005 10:54:36 +0900

Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.
>From [email-masked] Tue Sep 13 10:48:07 2005
Date: Tue, 13 Sep 2005 10:36:38 +0900
From: Soohong Daniel Park <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [16ng] Call for comments on 16ng BoF

Hello folks,

I and some of related people are trying to propose a new BoF at upcoming 64th IETF and the specific tasks are in progress. This issue aims to assist in doing a WiBro (IEEE 802.16) task. Here is existing charter of this BoF.

http://daniel.vsix.net/kwisf/wibrov6/charter.html 

Please make comments on this stuff and don't hesitate to ask further question.

This charter and mailing list will be officially available in the IETF, WiMAX Forum, 802.16 and related groups soon. Hopefully, I will send it to the IESG, if the status of charter and discussion are fully mature before cutoff.  

Regards,

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.
>From [email-masked] Tue Sep 13 15:32:21 2005
Date: Tue, 13 Sep 2005 15:20:39 +0900
From: Myung-Ki Shin <[email-masked]>
Organization: ETRI
To: Soohong Daniel Park <[email-masked]>, [email-masked],
   [email-masked]
Subject: [16ng] Re: Call for comments on 16ng BoF

Technical comments ...

In addition, as for the neighbor discovery issues, 
current ETRI Wibro implementation (IPv4) does not use ARP.
Thus, IPv6 ND issues would be the same as ARP ones.

I think like 3gpp, (at least) some ND messages can be 
unncessary in certain cases. There are no link layer addresses.
Therefore, address resolution and next hop determination 
are not needed.   

Miminum recommendatation could be NUD (Neighbor unreachability
detection), which is performed only for neighbors to
which unicast packets are sent.

So, a more interesting one is to point out supporting 
multiple interface with different ND characteristics in a host(MSS). 
(e.g., 802.11 + 802.16 both support) 

Any thought ?

Myung-Ki,

Myung-Ki Shin wrote:
> 
> Daniel,
> 
> I think it would be the good start for the BoF.
> 
> I'm also trying to make a draft on "A consideration of IPv6 in
> IEEE802.16 networks".
> 
> So, I can share my idea with you.
> 
> As for the charter, we need to discuss about the scope and goal more ...
> Also, we should define problems clearly before sending the proposed
> charter to IESG.
> (I couldn't see the problems beyond ND in the proposed charter)
> 
> See comments below.
> 
> Soohong Daniel Park wrote:
> 
> > I and some of related people are trying to propose a new BoF at upcoming 64th IETF and the specific tasks are in progress. This issue aims to assist in doing a WiBro (IEEE 802.16) task. Here is existing charter of this BoF.
> >
> > http://daniel.vsix.net/kwisf/wibrov6/charter.html
> >
> > Please make comments on this stuff and don't hesitate to ask further question.
> >
> 
> 
> ---- cut here ----------
> 
> IPv6 over IEEE 802.16(e) Networks (16ng)
> 
> => I think the wg name 16ng has too broad meaning. Also,
>    to make a wg in IETF, it's better to include IP issues
>    in the name rather than 16xxx.
> 
>    I prefer a 6xxx, e.g., 6wiman, ..
> 
> Last Modified: 2005-09-10
> 
> Chair(s):
> 
> Soohong Daniel Park<[email-masked]>
> TBD
> 
> Internet Area Director(s):
> 
> Mark Townsly<[email-masked]>
> Margaret Wasserman<[email-masked]>
> 
> Mailing Lists:
> 
> General Discussion: [email-masked]
> To Subscribe: http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> Archive: http://eeca16.sogang.ac.kr/pipermail/16ng
> 
> Description of Working Group:
> 
> Broadband Wireless Access Network was invented to overcome the low
> bandwidth wireless communication which was not appropriate for the user
> requirements such as high quality data/voice service, fast mobility,
> wide
> coverage and etc. To achieve these requirements, the IEEE 802.16 Working
> Group on Broadband Wireless Access Standards develops standards and
> recommended practices to support the development and deployment of
> broadband Wireless Metropolitan Area Networks. In addition, IEEE 802.16e
> supports mobility over IEEE 802.16 as an amendment of the IEEE 802.16
> specification.
> 
> Recently, much work is in progress by the WiMAX Forum. In particular,
> its
> NWG (Network Working Group) is responsible for the IEEE 802.16(e)
> network
> architecture (e.g., IPv4, IPv6, Mobility, Interworking with different
> networks,
> AAA, etc). The NWG is thus taking on work at layers above those defined
> by IEEE 802 standard (typically limited to the physical and link layers
> only).
> 
> IEEE 802.16(e) is significantly different from existing wireless access
> technology
> such as IEEE 802.11, and there are lots of considerable aspects to be
> resolved by
> IETF when applying Internet Protocol for IEEE 802.16(e) link.
> Expecially,
> IPv6 Neighbor Discovery does not work over IEEE 802.16(e) link. A key
> assumption made by Neighbor Discovery's actual protocol is that the link
> technology underlying a given IP interface is capable of native
> multicasting.
> This is, however, not true of IEEE 802.16(e) network although it belongs
> to
> IEEE 802 protocol not Non-Broadcast Multicast Access networks like ATM
> and Frame relay. Eventually, IEEE 802.16(e) requires convergence
> protocols
> to emulate the desired service on the network entiry such as BS and IPv6
> features will be limited. In addition, the characteristics of IEEE
> 802.16e
> link-layer operation require an amendment of existing Fast Handover
> Mobile
> IPv6 scheme (RFC 4068).
> 
> The principal objective of this working group is to make sure what
> limitation
> and consideration happen to IPv6 adoption over IEEE 802.16(e) network
> and
> propose available solutions. In addition, this working group arguments
> and
> optimizes the IEEE 802.16(e) protocol for use in support of IPv6
> Neighbor
> Discovery. In addition, the working group will work and coordinate with
> WiMAX
> Forum especially NWG and such related groups.
> 
> In the case of IPv6, it remains a future work of current WiMAX Forum
> specification to be begun next year. However, WiMAX Forum does not
> define any new Internet Protocols by itself regardless of protocol
> limitations.
> Consequently, Internet Protocol limitations should be resolved by IETF.
> 
> => General comments on description of wg
> 
>    Maybe, IESG will ask the relationship of WiMAX Forum and its future
> works e.g., standards,
>    since some WiMAX forum works are mentioned here.
> 
>    In my opinion, we define a more specific scope to
>    eliminate dependency with WiMAX Forum.
> 
>    Also, if we focus on general IPv6 issues (not, mobility or
> *IP-related-
>    -specific* issues in IEEE802.16),
>    I suggest to follow-up the general steps for Internet Area's (IP over
> xxx) WG.
> 
>    1) define problems and goal
>    2) produce one document to describe them
>    3) if some changes or extensions are required to current IP specs,
>       document seperated drafts to update each issues ...
> 
>    One proposal could be (of course we need to investigate each issue
> first
>    to figure out what problems are or not) ...
> 
>    * Basic IP issues - ND, Transmission of packets, Path MTU,
> addressing, ..
>    * Mobility - Interworking with FMIP6, L2/L3 mobility interworking
> ...
>    * Multicast
>    * Security
>    * Multiple interface with different properties (e.g., 802.11 + 802.16
> both support)
>    * Interworking with different networks
> 
> The scope of this working group is as follows;
> 
> Note; this working group is only focusing on IPv6 since IPv4 issues are
> under
> control. Whereas at least some of the valuable efforts on IPv4 could be
> documented
> in IETF as an individual process.
> 
>   => What does mean "IPv4 issues are under control" ?
>      We need to describe the reason clearly ..
> 
> -  Produce “Problem Statements for IPv6 over IEEE 802.16(e) Networks”
> to sense the problem and limitation of IPv6 adoption over IEEE 802.16(e)
> networks.
> [Informational RFC]
> 
> -  Produce "Fast Handover Mobile IPv6 over IEEE 802.16e Networks" to
> define
> the fast handover scheme for mobile IPv6 (RFC 3775) over IEEE 802.16e
> link.
> [Informational RFC]
> 
> -  Product "IPv6 over IEEE 802.16(e)" to define the transmission of IPv6
> over
> IEEE 802.16(e) link for use in support of IPv6 Neighbor Discovery.
> [Standard RFC]
> 
> This working group will reuse existing specifications whenever
> reasonable and
> possible.
> 
> Goals and Milestones:
> 
>   Dec 05
> 
>                          Submit Internet-Daft on problem statements to
> IESG for consideration of publication as Informational RFC
>   Feb 05
> 
>                          Submit Internet-Draft on FMIP6 over IEEE
> 802.16e to IESG for consideration of publication as Informational RFC
>   July 06
> 
>                          Submit Internet-Draft on IPv6 over IEEE
> 802.16(e) to IESG for consideration of publication as Proposed Standard
>                          RFC
> 
> 
> Internet-Drafts:
> 
> Mobile IPv6 Fast Handover over IEEE 802.16e Networks
> Transmission of IPv6 Packets over IEEE802.16 Networks
> IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon)
> 
> Related links:
> 
> BoF Procedures
> Important Dates for the 64th IETF Meeting
> WiMAX Forum Homepage
> IEEE 802.16 Task Group e (Mobile Wireless MAN)
> 
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Myung-Ki Shin, Ph.D.| [email-masked]
> ETRI/PEC            | 161 Gajeong-dong Yuseong-gu
> Tel:+82-42-860-4847 | Daejeon, 305-350 Korea

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 
Myung-Ki Shin, Ph.D.| [email-masked]
ETRI/PEC            | 161 Gajeong-dong Yuseong-gu 
Tel:+82-42-860-4847 | Daejeon, 305-350 Korea
>From [email-masked] Tue Sep 13 16:11:56 2005
Date: Tue, 13 Sep 2005 16:00:21 +0900
From: YounHee Han <[email-masked]>
To: Myung-Ki Shin <[email-masked]>
Subject: Re: [16ng] Re: Call for comments on 16ng BoF
cc: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]

------=_Part_15914_23470413.1126594821472
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,
 Thank you for bringing up technical issue.
 In some presentation, I talked about the following issues in ipv6/wibro=20
problem space.
- router (prefix) discovery,
- stateless address auto-configuration,
- address resolution,=20
- next-hop determination,=20
- NUD,
- Redirect
- Multicast address mapping of ND-related messages
- MLD
 As said by Myung-Ki, in 802.16 specification (802.16-2004),=20
address resolution function seems to be already addressed=20
in Section 5.2.2 'classification'. We can expect that=20
ACR device of WiBro will implement the classification
function in its convergence sub-layer.
 The classification function is only applied to the downward packets=20
(packets come from network to terminal) and implemented inside ACR.=20
How about upward packets (packets from terminal to network or terminal)?
Classification is not related to terminal. So, the simple solution is to
fix the resolution result of all addresses with "ACR's address"
It seems to be somewhat controversial. Any comments?
 Regarding next-hop determination, the solution seems to be
similar with the above.
 I roughly agree with Myung-Ki. But, I don't want to firmly conclude that
"address resolution and next hop determination are not needed"
It's one of 3gpp's sentence :-) Instead of it, we can say that...
"address resolution and next hop determination can be simply implemented"
 - Youn-Hee Han (Ph.D.)
Samsung Advanced Institute of Technology
 On 9/13/05, Myung-Ki Shin <[email-masked]> wrote:
=20
> Technical comments ...
>=20
> In addition, as for the neighbor discovery issues,
> current ETRI Wibro implementation (IPv4) does not use ARP.
> Thus, IPv6 ND issues would be the same as ARP ones.
>=20
> I think like 3gpp, (at least) some ND messages can be
> unncessary in certain cases. There are no link layer addresses.
> Therefore, address resolution and next hop determination
> are not needed.
>=20
> Miminum recommendatation could be NUD (Neighbor unreachability
> detection), which is performed only for neighbors to
> which unicast packets are sent.
>=20
> So, a more interesting one is to point out supporting
> multiple interface with different ND characteristics in a host(MSS).
> (e.g., 802.11 + 802.16 both support)
>=20
> Any thought ?
>=20
> Myung-Ki,
>=20
> Myung-Ki Shin wrote:
> >
> > Daniel,
> >
> > I think it would be the good start for the BoF.
> >
> > I'm also trying to make a draft on "A consideration of IPv6 in
> > IEEE802.16 networks".
> >
> > So, I can share my idea with you.
> >
> > As for the charter, we need to discuss about the scope and goal more ..=
.
> > Also, we should define problems clearly before sending the proposed
> > charter to IESG.
> > (I couldn't see the problems beyond ND in the proposed charter)
> >
> > See comments below.
> >
> > Soohong Daniel Park wrote:
> >
> > > I and some of related people are trying to propose a new BoF at=20
> upcoming 64th IETF and the specific tasks are in progress. This issue aim=
s=20
> to assist in doing a WiBro (IEEE 802.16) task. Here is existing charter o=
f=20
> this BoF.
> > >
> > > http://daniel.vsix.net/kwisf/wibrov6/charter.html
> > >
> > > Please make comments on this stuff and don't hesitate to ask further=
=20
> question.
> > >
> >
> >
> > ---- cut here ----------
> >
> > IPv6 over IEEE 802.16(e) Networks (16ng)
> >
> > =3D> I think the wg name 16ng has too broad meaning. Also,
> > to make a wg in IETF, it's better to include IP issues
> > in the name rather than 16xxx.
> >
> > I prefer a 6xxx, e.g., 6wiman, ..
> >
> > Last Modified: 2005-09-10
> >
> > Chair(s):
> >
> > Soohong Daniel Park<[email-masked]>
> > TBD
> >
> > Internet Area Director(s):
> >
> > Mark Townsly<[email-masked]>
> > Margaret Wasserman<[email-masked]>
> >
> > Mailing Lists:
> >
> > General Discussion: [email-masked]
> > To Subscribe: http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
> > Archive: http://eeca16.sogang.ac.kr/pipermail/16ng
> >
> > Description of Working Group:
> >
> > Broadband Wireless Access Network was invented to overcome the low
> > bandwidth wireless communication which was not appropriate for the user
> > requirements such as high quality data/voice service, fast mobility,
> > wide
> > coverage and etc. To achieve these requirements, the IEEE 802.16 Workin=
g
> > Group on Broadband Wireless Access Standards develops standards and
> > recommended practices to support the development and deployment of
> > broadband Wireless Metropolitan Area Networks. In addition, IEEE 802.16=
e
> > supports mobility over IEEE 802.16 as an amendment of the IEEE 802.16
> > specification.
> >
> > Recently, much work is in progress by the WiMAX Forum. In particular,
> > its
> > NWG (Network Working Group) is responsible for the IEEE 802.16(e)
> > network
> > architecture (e.g., IPv4, IPv6, Mobility, Interworking with different
> > networks,
> > AAA, etc). The NWG is thus taking on work at layers above those defined
> > by IEEE 802 standard (typically limited to the physical and link layers
> > only).
> >
> > IEEE 802.16(e) is significantly different from existing wireless access
> > technology
> > such as IEEE 802.11, and there are lots of considerable aspects to be
> > resolved by
> > IETF when applying Internet Protocol for IEEE 802.16(e) link.
> > Expecially,
> > IPv6 Neighbor Discovery does not work over IEEE 802.16(e) link. A key
> > assumption made by Neighbor Discovery's actual protocol is that the lin=
k
> > technology underlying a given IP interface is capable of native
> > multicasting.
> > This is, however, not true of IEEE 802.16(e) network although it belong=
s
> > to
> > IEEE 802 protocol not Non-Broadcast Multicast Access networks like ATM
> > and Frame relay. Eventually, IEEE 802.16(e) requires convergence
> > protocols
> > to emulate the desired service on the network entiry such as BS and IPv=
6
> > features will be limited. In addition, the characteristics of IEEE
> > 802.16e
> > link-layer operation require an amendment of existing Fast Handover
> > Mobile
> > IPv6 scheme (RFC 4068).
> >
> > The principal objective of this working group is to make sure what
> > limitation
> > and consideration happen to IPv6 adoption over IEEE 802.16(e) network
> > and
> > propose available solutions. In addition, this working group arguments
> > and
> > optimizes the IEEE 802.16(e) protocol for use in support of IPv6
> > Neighbor
> > Discovery. In addition, the working group will work and coordinate with
> > WiMAX
> > Forum especially NWG and such related groups.
> >
> > In the case of IPv6, it remains a future work of current WiMAX Forum
> > specification to be begun next year. However, WiMAX Forum does not
> > define any new Internet Protocols by itself regardless of protocol
> > limitations.
> > Consequently, Internet Protocol limitations should be resolved by IETF.
> >
> > =3D> General comments on description of wg
> >
> > Maybe, IESG will ask the relationship of WiMAX Forum and its future
> > works e.g., standards,
> > since some WiMAX forum works are mentioned here.
> >
> > In my opinion, we define a more specific scope to
> > eliminate dependency with WiMAX Forum.
> >
> > Also, if we focus on general IPv6 issues (not, mobility or
> > *IP-related-
> > -specific* issues in IEEE802.16),
> > I suggest to follow-up the general steps for Internet Area's (IP over
> > xxx) WG.
> >
> > 1) define problems and goal
> > 2) produce one document to describe them
> > 3) if some changes or extensions are required to current IP specs,
> > document seperated drafts to update each issues ...
> >
> > One proposal could be (of course we need to investigate each issue
> > first
> > to figure out what problems are or not) ...
> >
> > * Basic IP issues - ND, Transmission of packets, Path MTU,
> > addressing, ..
> > * Mobility - Interworking with FMIP6, L2/L3 mobility interworking
> > ...
> > * Multicast
> > * Security
> > * Multiple interface with different properties (e.g., 802.11 + 802.16
> > both support)
> > * Interworking with different networks
> >
> > The scope of this working group is as follows;
> >
> > Note; this working group is only focusing on IPv6 since IPv4 issues are
> > under
> > control. Whereas at least some of the valuable efforts on IPv4 could be
> > documented
> > in IETF as an individual process.
> >
> > =3D> What does mean "IPv4 issues are under control" ?
> > We need to describe the reason clearly ..
> >
> > - Produce =A1=B0Problem Statements for IPv6 over IEEE 802.16(e) Network=
s=A1=B1
> > to sense the problem and limitation of IPv6 adoption over IEEE 802.16(e=
)
> > networks.
> > [Informational RFC]
> >
> > - Produce "Fast Handover Mobile IPv6 over IEEE 802.16e Networks" to
> > define
> > the fast handover scheme for mobile IPv6 (RFC 3775) over IEEE 802.16e
> > link.
> > [Informational RFC]
> >
> > - Product "IPv6 over IEEE 802.16(e)" to define the transmission of IPv6
> > over
> > IEEE 802.16(e) link for use in support of IPv6 Neighbor Discovery.
> > [Standard RFC]
> >
> > This working group will reuse existing specifications whenever
> > reasonable and
> > possible.
> >
> > Goals and Milestones:
> >
> > Dec 05
> >
> > Submit Internet-Daft on problem statements to
> > IESG for consideration of publication as Informational RFC
> > Feb 05
> >
> > Submit Internet-Draft on FMIP6 over IEEE
> > 802.16e to IESG for consideration of publication as Informational RFC
> > July 06
> >
> > Submit Internet-Draft on IPv6 over IEEE
> > 802.16(e) to IESG for consideration of publication as Proposed Standard
> > RFC
> >
> >
> > Internet-Drafts:
> >
> > Mobile IPv6 Fast Handover over IEEE 802.16e Networks
> > Transmission of IPv6 Packets over IEEE802.16 Networks
> > IPv6 over IEEE 802.16(e) Networks Problem Statements (coming soon)
> >
> > Related links:
> >
> > BoF Procedures
> > Important Dates for the 64th IETF Meeting
> > WiMAX Forum Homepage
> > IEEE 802.16 Task Group e (Mobile Wireless MAN)
> >
> > --
> > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D-=3D
> > Myung-Ki Shin, Ph.D.| [email-masked]
> > ETRI/PEC | 161 Gajeong-dong Yuseong-gu
> > Tel:+82-42-860-4847 | Daejeon, 305-350 Korea
>=20
> --
> =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D
> Myung-Ki Shin, Ph.D.| [email-masked]
> ETRI/PEC | 161 Gajeong-dong Yuseong-gu
> Tel:+82-42-860-4847 | Daejeon, 305-350 Korea
> _______________________________________________
> 16ng mailing list
> [email-masked]
> http://eeca16.sogang.ac.kr/mailman/listinfo/16ng
>

------=_Part_15914_23470413.1126594821472
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<div>&nbsp;</div>
<div>Hello,</div>
<div>&nbsp;</div>
<div>Thank you for bringing up technical issue.</div>
<div>&nbsp;</div>
<div>In some presentation, I talked about the following issues in ipv6/wibr=
o problem space.</div>
<div>- router (prefix) discovery,</div>
<div>- stateless address auto-configuration,</div>
<div>- address resolution, </div>
<div>- next-hop determination, </div>
<div>- NUD,</div>
<div>- Redirect</div>
<div>- Multicast address mapping of ND-related messages</div>
<div>- MLD</div>
<div>&nbsp;</div>
<div>As said by Myung-Ki, in 802.16 specification (802.16-2004), </div>
<div>address resolution function&nbsp;seems to be&nbsp;already&nbsp;address=
ed </div>
<div>in Section 5.2.2 'classification'. We can expect that </div>
<div>ACR device of WiBro will implement the classification</div>
<div>function in its convergence sub-layer.</div>
<div>&nbsp;</div>
<div>The classification function&nbsp;is only applied&nbsp;to the downward =
packets </div>
<div>(packets come from network to terminal) and implemented inside ACR. </=
div>
<div>How about upward packets (packets from terminal to network or terminal=
)?</div>
<div>Classification is not related to terminal. So, the simple solution is =
to</div>
<div>fix&nbsp;the&nbsp;resolution result of all addresses with&nbsp;&quot;A=
CR's address&quot;</div>
<div>It seems to be&nbsp;somewhat controversial. Any comments?</div>
<div>&nbsp;</div>
<div>Regarding next-hop determination, the solution seems to be</div>
<div>similar with the above.</div>
<div>&nbsp;</div>
<div>I roughly agree with Myung-Ki. But, I don't want to firmly&nbsp;conclu=
de that</div>
<div>&quot;address resolution and next hop determination are not needed&quo=
t;</div>
<div>It's one of 3gpp's&nbsp;sentence :-)&nbsp;&nbsp; Instead of it, we can=
 say that...</div>
<div>&quot;address resolution and next hop determination can be simply impl=
emented&quot;</div>
<div>&nbsp;</div>
<div>- Youn-Hee Han (Ph.D.)</div>
<div>Samsung Advanced Institute of Technology</div>
<div>&nbsp;</div>
<div><span class=3D"gmail_quote">On 9/13/05, <b class=3D"gmail_sendername">=
Myung-Ki Shin</b> &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
tri.re.kr</a>&gt; wrote:</span></div>
<div>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Technical comments ...<br><br>In=
 addition, as for the neighbor discovery issues,<br>current ETRI Wibro impl=
ementation (IPv4) does not use ARP.
<br>Thus, IPv6 ND issues would be the same as ARP ones.<br><br>I think like=
 3gpp, (at least) some ND messages can be<br>unncessary in certain cases. T=
here are no link layer addresses.<br>Therefore, address resolution and next=
 hop determination
<br>are not needed.<br><br>Miminum recommendatation could be NUD (Neighbor =
unreachability<br>detection), which is performed only for neighbors to<br>w=
hich unicast packets are sent.<br><br>So, a more interesting one is to poin=
t out supporting
<br>multiple interface with different ND characteristics in a host(MSS).<br=
>(e.g., 802.11 + 802.16 both support)<br><br>Any thought ?<br><br>Myung-Ki,=
<br><br>Myung-Ki Shin wrote:<br>&gt;<br>&gt; Daniel,<br>&gt;<br>&gt; I thin=
k it would be the good start for the BoF.
<br>&gt;<br>&gt; I'm also trying to make a draft on &quot;A consideration o=
f IPv6 in<br>&gt; IEEE802.16 networks&quot;.<br>&gt;<br>&gt; So, I can shar=
e my idea with you.<br>&gt;<br>&gt; As for the charter, we need to discuss =
about the scope and goal more ...
<br>&gt; Also, we should define problems clearly before sending the propose=
d<br>&gt; charter to IESG.<br>&gt; (I couldn't see the problems beyond ND i=
n the proposed charter)<br>&gt;<br>&gt; See comments below.<br>&gt;<br>
&gt; Soohong Daniel Park wrote:<br>&gt;<br>&gt; &gt; I and some of related =
people are trying to propose a new BoF at upcoming 64th IETF and the specif=
ic tasks are in progress. This issue aims to assist in doing a WiBro (IEEE=
=20
802.16) task. Here is existing charter of this BoF.<br>&gt; &gt;<br>&gt; &g=
t; <a href=3D"http://daniel.vsix.net/kwisf/wibrov6/charter.html">http://dan=
iel.vsix.net/kwisf/wibrov6/charter.html</a><br>&gt; &gt;<br>&gt; &gt; Pleas=
e make comments on this stuff and don't hesitate to ask further question.
<br>&gt; &gt;<br>&gt;<br>&gt;<br>&gt; ---- cut here ----------<br>&gt;<br>&=
gt; IPv6 over IEEE 802.16(e) Networks (16ng)<br>&gt;<br>&gt; =3D&gt; I thin=
k the wg name 16ng has too broad meaning. Also,<br>&gt;&nbsp;&nbsp;&nbsp;&n=
bsp;to make a wg in IETF, it's better to include IP issues
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;in the name rather than 16xxx.<br>&gt;<br>&=
gt;&nbsp;&nbsp;&nbsp;&nbsp;I prefer a 6xxx, e.g., 6wiman, ..<br>&gt;<br>&gt=
; Last Modified: 2005-09-10<br>&gt;<br>&gt; Chair(s):<br>&gt;<br>&gt; Sooho=
ng Daniel Park&lt;<a href=3D"mailto:[email-masked]">
[email-masked]</a>&gt;<br>&gt; TBD<br>&gt;<br>&gt; Internet Area =
Director(s):<br>&gt;<br>&gt; Mark Townsly&lt;<a href=3D"mailto:townsley@cis=
co.com">[email-masked]</a>&gt;<br>&gt; Margaret Wasserman&lt;<a href=3D=
"mailto:[email-masked]">
[email-masked]</a>&gt;<br>&gt;<br>&gt; Mailing Lists:<br>&gt;<br>&=
gt; General Discussion: <a href=3D"mailto:[email-masked]">16ng@ee=
ca16.sogang.ac.kr</a><br>&gt; To Subscribe: <a href=3D"http://eeca16.sogang=
.ac.kr/mailman/listinfo/16ng">
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng</a><br>&gt; Archive: <a hr=
ef=3D"http://eeca16.sogang.ac.kr/pipermail/16ng">http://eeca16.sogang.ac.kr=
/pipermail/16ng</a><br>&gt;<br>&gt; Description of Working Group:<br>&gt;
<br>&gt; Broadband Wireless Access Network was invented to overcome the low=
<br>&gt; bandwidth wireless communication which was not appropriate for the=
 user<br>&gt; requirements such as high quality data/voice service, fast mo=
bility,
<br>&gt; wide<br>&gt; coverage and etc. To achieve these requirements, the =
IEEE 802.16 Working<br>&gt; Group on Broadband Wireless Access Standards de=
velops standards and<br>&gt; recommended practices to support the developme=
nt and deployment of
<br>&gt; broadband Wireless Metropolitan Area Networks. In addition, IEEE 8=
02.16e<br>&gt; supports mobility over IEEE 802.16 as an amendment of the IE=
EE 802.16<br>&gt; specification.<br>&gt;<br>&gt; Recently, much work is in =
progress by the WiMAX Forum. In particular,
<br>&gt; its<br>&gt; NWG (Network Working Group) is responsible for the IEE=
E 802.16(e)<br>&gt; network<br>&gt; architecture (e.g., IPv4, IPv6, Mobilit=
y, Interworking with different<br>&gt; networks,<br>&gt; AAA, etc). The NWG=
 is thus taking on work at layers above those defined
<br>&gt; by IEEE 802 standard (typically limited to the physical and link l=
ayers<br>&gt; only).<br>&gt;<br>&gt; IEEE 802.16(e) is significantly differ=
ent from existing wireless access<br>&gt; technology<br>&gt; such as IEEE=
=20
802.11, and there are lots of considerable aspects to be<br>&gt; resolved b=
y<br>&gt; IETF when applying Internet Protocol for IEEE 802.16(e) link.<br>=
&gt; Expecially,<br>&gt; IPv6 Neighbor Discovery does not work over IEEE=20
802.16(e) link. A key<br>&gt; assumption made by Neighbor Discovery's actua=
l protocol is that the link<br>&gt; technology underlying a given IP interf=
ace is capable of native<br>&gt; multicasting.<br>&gt; This is, however, no=
t true of IEEE=20
802.16(e) network although it belongs<br>&gt; to<br>&gt; IEEE 802 protocol =
not Non-Broadcast Multicast Access networks like ATM<br>&gt; and Frame rela=
y. Eventually, IEEE 802.16(e) requires convergence<br>&gt; protocols<br>
&gt; to emulate the desired service on the network entiry such as BS and IP=
v6<br>&gt; features will be limited. In addition, the characteristics of IE=
EE<br>&gt; 802.16e<br>&gt; link-layer operation require an amendment of exi=
sting Fast Handover
<br>&gt; Mobile<br>&gt; IPv6 scheme (RFC 4068).<br>&gt;<br>&gt; The princip=
al objective of this working group is to make sure what<br>&gt; limitation<=
br>&gt; and consideration happen to IPv6 adoption over IEEE 802.16(e) netwo=
rk
<br>&gt; and<br>&gt; propose available solutions. In addition, this working=
 group arguments<br>&gt; and<br>&gt; optimizes the IEEE 802.16(e) protocol =
for use in support of IPv6<br>&gt; Neighbor<br>&gt; Discovery. In addition,=
 the working group will work and coordinate with
<br>&gt; WiMAX<br>&gt; Forum especially NWG and such related groups.<br>&gt=
;<br>&gt; In the case of IPv6, it remains a future work of current WiMAX Fo=
rum<br>&gt; specification to be begun next year. However, WiMAX Forum does =
not
<br>&gt; define any new Internet Protocols by itself regardless of protocol=
<br>&gt; limitations.<br>&gt; Consequently, Internet Protocol limitations s=
hould be resolved by IETF.<br>&gt;<br>&gt; =3D&gt; General comments on desc=
ription of wg
<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Maybe, IESG will ask the relationsh=
ip of WiMAX Forum and its future<br>&gt; works e.g., standards,<br>&gt;&nbs=
p;&nbsp;&nbsp;&nbsp;since some WiMAX forum works are mentioned here.<br>&gt=
;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;In my opinion, we define a more specific s=
cope to
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;eliminate dependency with WiMAX Forum.<br>&=
gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;Also, if we focus on general IPv6 issues=
 (not, mobility or<br>&gt; *IP-related-<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;-spe=
cific* issues in IEEE802.16),<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;I suggest to f=
ollow-up the general steps for Internet Area's (IP over
<br>&gt; xxx) WG.<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;1) define problems=
 and goal<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;2) produce one document to describ=
e them<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;3) if some changes or extensions are =
required to current IP specs,<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; d=
ocument seperated drafts to update each issues ...
<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;One proposal could be (of course we=
 need to investigate each issue<br>&gt; first<br>&gt;&nbsp;&nbsp;&nbsp;&nbs=
p;to figure out what problems are or not) ...<br>&gt;<br>&gt;&nbsp;&nbsp;&n=
bsp;&nbsp;* Basic IP issues - ND, Transmission of packets, Path MTU,
<br>&gt; addressing, ..<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;* Mobility - Interwo=
rking with FMIP6, L2/L3 mobility interworking<br>&gt; ...<br>&gt;&nbsp;&nbs=
p;&nbsp;&nbsp;* Multicast<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;* Security<br>&gt;=
&nbsp;&nbsp;&nbsp;&nbsp;* Multiple interface with different properties (e.g=
.,=20
802.11 + 802.16<br>&gt; both support)<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;* Inte=
rworking with different networks<br>&gt;<br>&gt; The scope of this working =
group is as follows;<br>&gt;<br>&gt; Note; this working group is only focus=
ing on IPv6 since IPv4 issues are
<br>&gt; under<br>&gt; control. Whereas at least some of the valuable effor=
ts on IPv4 could be<br>&gt; documented<br>&gt; in IETF as an individual pro=
cess.<br>&gt;<br>&gt;&nbsp;&nbsp; =3D&gt; What does mean &quot;IPv4 issues =
are under control&quot; ?
<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;We need to describe the reason =
clearly ..<br>&gt;<br>&gt; -&nbsp;&nbsp;Produce =A1=B0Problem Statements fo=
r IPv6 over IEEE 802.16(e) Networks=A1=B1<br>&gt; to sense the problem and =
limitation of IPv6 adoption over IEEE 802.16
(e)<br>&gt; networks.<br>&gt; [Informational RFC]<br>&gt;<br>&gt; -&nbsp;&n=
bsp;Produce &quot;Fast Handover Mobile IPv6 over IEEE 802.16e Networks&quot=
; to<br>&gt; define<br>&gt; the fast handover scheme for mobile IPv6 (RFC 3=
775) over IEEE=20
802.16e<br>&gt; link.<br>&gt; [Informational RFC]<br>&gt;<br>&gt; -&nbsp;&n=
bsp;Product &quot;IPv6 over IEEE 802.16(e)&quot; to define the transmission=
 of IPv6<br>&gt; over<br>&gt; IEEE 802.16(e) link for use in support of IPv=
6 Neighbor Discovery.
<br>&gt; [Standard RFC]<br>&gt;<br>&gt; This working group will reuse exist=
ing specifications whenever<br>&gt; reasonable and<br>&gt; possible.<br>&gt=
;<br>&gt; Goals and Milestones:<br>&gt;<br>&gt;&nbsp;&nbsp; Dec 05<br>&gt;<=
br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;Submit Internet-Daft on problem statements to
<br>&gt; IESG for consideration of publication as Informational RFC<br>&gt;=
&nbsp;&nbsp; Feb 05<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Submit Internet-Draft on FMIP6 ove=
r IEEE<br>&gt; 802.16e to IESG for consideration of publication as Informat=
ional RFC
<br>&gt;&nbsp;&nbsp; July 06<br>&gt;<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Submit Internet-Draft on =
IPv6 over IEEE<br>&gt; 802.16(e) to IESG for consideration of publication a=
s Proposed Standard<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RFC<br>&gt;
<br>&gt;<br>&gt; Internet-Drafts:<br>&gt;<br>&gt; Mobile IPv6 Fast Handover=
 over IEEE 802.16e Networks<br>&gt; Transmission of IPv6 Packets over IEEE8=
02.16 Networks<br>&gt; IPv6 over IEEE 802.16(e) Networks Problem Statements=
 (coming soon)
<br>&gt;<br>&gt; Related links:<br>&gt;<br>&gt; BoF Procedures<br>&gt; Impo=
rtant Dates for the 64th IETF Meeting<br>&gt; WiMAX Forum Homepage<br>&gt; =
IEEE 802.16 Task Group e (Mobile Wireless MAN)<br>&gt;<br>&gt; --<br>&gt; =
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D-=3D-=3D-=3D-=3D
<br>&gt; Myung-Ki Shin, Ph.D.| <a href=3D"mailto:[email-masked]">mks=
[email-masked]</a><br>&gt; ETRI/PEC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;| 161 Gajeong-dong Yuseong-gu<br>&gt; T=
el:+82-42-860-4847 | Daejeon, 305-350 Korea<br><br>--<br>=3D-=3D-=3D-=3D-=
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D-=3D
<br>Myung-Ki Shin, Ph.D.| <a href=3D"mailto:[email-masked]">mkshin@p=
ec.etri.re.kr</a><br>ETRI/PEC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;| 161 Gajeong-dong Yuseong-gu<br>Tel:+82-42-860-4=
847 | Daejeon, 305-350 Korea<br>___________________________________________=
____
<br>16ng mailing list<br><a href=3D"mailto:[email-masked]">16ng@e=
eca16.sogang.ac.kr</a><br><a href=3D"http://eeca16.sogang.ac.kr/mailman/lis=
tinfo/16ng">http://eeca16.sogang.ac.kr/mailman/listinfo/16ng</a><br></block=
quote>
</div><br>

------=_Part_15914_23470413.1126594821472--
>From [email-masked] Tue Sep 13 16:56:20 2005
Date: Tue, 13 Sep 2005 16:44:50 +0900
From: Myung-Ki Shin <[email-masked]>
Organization: ETRI
To: [email-masked]
Subject: Re: [16ng] Re: Call for comments on 16ng BoF
cc: [email-masked]
cc: [email-masked]

Hi,

At this phase, I don't want to discuss about solutions ...
I'm just saying it is really a problem or not.

e.g., as for the ND issues, if we conclude *address 
resolution and next hop determination are not needed* or 
*address resolution and next hop determination can be 
simply implemented*, any statement will be not a problem, 
just one of implementation considerations, I think.

My intention was to figure out problems to put them
in charter items.  

Back to the general comments on propsoed charter, 
we should focus on the scope according to problem statement 
discussion. (to create wg :)

We can say ND may be a problem just in 802.16 networks ? 
 
Thanks,
Myung-Ki,
>From [email-masked] Tue Sep 13 17:30:57 2005
From: "Younhee Han" <[email-masked]>
To: "Myung-Ki Shin" <[email-masked]>
Subject: Re: [16ng] Re: Call for comments on 16ng BoF
Date: Tue, 13 Sep 2005 17:19:21 +0900
cc: [email-masked]
cc: [email-masked]

> At this phase, I don't want to discuss about solutions ...
> I'm just saying it is really a problem or not.
> 
> e.g., as for the ND issues, if we conclude *address 
> resolution and next hop determination are not needed* or 
> *address resolution and next hop determination can be 
> simply implemented*, any statement will be not a problem, 
> just one of implementation considerations, I think.
>
> My intention was to figure out problems to put them
> in charter items.  
>
> Back to the general comments on propsoed charter, 
> we should focus on the scope according to problem statement 
> discussion. (to create wg :)

Yes. I understand your point. 
I really want to focus the problem definition, too.

My intention was just asking a favor to you 
that we should take a different view from IPv6/3gpp 
when we talking about  IPv6/Wibro issues.
 
> We can say ND may be a problem just in 802.16 networks ? 

In my opinion, ND can be a problem in IPv6/WiBro in terms of 
the multicast method of ND messages.

Now, I'd like to raise another issues related to ND problem.

1) Should we support the stateless address configuration in 802.16 networks?
2) If it should be supported, how to defend the address conflict?

If we try to solve the address conflict by using RFC 2462 DAD solution,
the following issue can be also brought up:

3) How to deliver NS message with the solicited-node multicast address as its destination?

Definitely, the issue 3) is related to ND 

- Youn-Hee