Skip to main content

IPv6 Deployment Scenarios in 802.16 Networks
RFC 5181

Revision differences

Document history

Date Rev. By Action
2017-05-16
07 (System) Changed document authors from "Myung-Ki Shin" to "Myung-Ki Shin, Sang-Eon Kim, Youn-Hee Han, Domagoj Premec"
2015-10-14
07 (System) Notify list changed from v6ops-chairs@ietf.org to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Tim Polk
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Russ Housley
2008-05-09
07 Cindy Morgan [Note]: 'RFC #5181' added by Cindy Morgan
2008-05-09
07 Cindy Morgan State Changes to RFC Published from RFC Ed Queue by Cindy Morgan
2008-05-09
07 (System) RFC published
2008-04-15
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-04-14
07 (System) IANA Action state changed to No IC from In Progress
2008-04-14
07 (System) IANA Action state changed to In Progress
2008-04-14
07 Amy Vezza IESG state changed to Approved-announcement sent
2008-04-14
07 Amy Vezza IESG has approved the document
2008-04-14
07 Amy Vezza Closed "Approve" ballot
2008-04-11
07 Ron Bonica State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ron Bonica
2008-04-09
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Undefined by Tim Polk
2008-04-09
07 Tim Polk [Ballot Position Update] Position for Tim Polk has been changed to Undefined from Discuss by Tim Polk
2008-04-07
07 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu
2008-02-28
07 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from No Objection by Jari Arkko
2008-02-28
07 Jari Arkko [Ballot comment]
2008-02-28
07 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2008-02-28
07 Jari Arkko [Ballot discuss]
2008-02-21
07 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley
2008-01-28
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2008-01-28
07 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-07.txt
2008-01-24
07 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2008-01-24
07 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2008-01-24
07 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-01-23
07 David Ward [Ballot comment]
I put no object only because others have covered my concerns and I will let them carry the discusses
2008-01-23
07 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-01-23
07 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2008-01-23
07 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2008-01-20
07 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-01-11
07 (System) Removed from agenda for telechat - 2008-01-10
2008-01-10
07 Samuel Weiler Request for Telechat review by SECDIR Completed. Reviewer: Julien Laganier.
2008-01-10
07 Ron Bonica
[Ballot comment]
These comments from Bert Wijnen:

Here are my comments:

- Security Considerations section points to sect 2.5
  But that section only concludes …
[Ballot comment]
These comments from Bert Wijnen:

Here are my comments:

- Security Considerations section points to sect 2.5
  But that section only concludes that
                                                        But, we do not
  have PKIs across organizations and IPsec is not integrated with IEEE
  802.16 network mobility management.

  IEEE 802.16 network threats may be different from IPv6 and IPv6
  transition threat models [RFC4942].  It should be also discussed

  I wonder if this is acceptable.

nits/TYPOS:

- SECTION 1.1, first bullet:
  o  Base Station (BS): A generalized equipment sets providing
      connectivity, management, and control between the subscriber
      station and the 802.16 networks.

  s/sets/set/ ?? At least to my ear

- Pls expand acronyms the furst time they are used. Examples
  are DAD, MN

- Section 2.6 talks about 3 connections. The first is the "base
  connection", then it speaks about "primary" and "secondary"
  connections. It feels somewhat strange to consider the
  2nd connection the "primary" and the 3rd connection the
  "secondary". It is not tstated that way... but I had to read
  a few times to understand what was meant. Maybe the text can be
  improved?

- 3rd para in section 2.6

  IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
  network elements are implemented dual stack.  For example, network

  I think I would s/managed by/manager over/
  or s/managed by/managed via/

- same 3rd para of section 2.6

  related object identifiers.  Also, an NMS can use IPv6 for SNMP
  requests and responses including IPv4 related OID.

  Not sure I understand what is meant with "IPv4 related OID."
  ???

- IDnits states:

  == Outdated reference: A later version (-04) exists of
    draft-ietf-16ng-ps-goals-03


Bert Wijnen
2008-01-10
07 Mark Townsley State Changes to IESG Evaluation - Defer from IESG Evaluation by Mark Townsley
2008-01-10
07 Tim Polk
[Ballot discuss]
As noted in Julien Laganier's secdir review, there are some problems
with the current text on security, as well as the security
considerations …
[Ballot discuss]
As noted in Julien Laganier's secdir review, there are some problems
with the current text on security, as well as the security
considerations section.

Section 2.5 IPv6 Security

It would be helpful if the implications for paragraphs one and two
were spelled out.  Paragraph three needs to move to security
considerations and the discussion added.

Paragraph 1:

  When initiating the connection, an MS is authenticated by the AAA
  server located at its service provider network.  All the parameters
  related to authentication (username, password and etc.) are forwarded
  by the BS to the AAA server.  The AAA server authenticates the MSs
  and when an MS is once authenticated and associated successfully with
  BS, IPv6 an address will be acquired by the MS through stateless
  autoconfiguration or DHCPv6.  Note the initiation and authentication
  process is the same as used in IPv4.

This implies that one important aspect of security for IPv6
over 802.16 is that authentication of an MS is required before
an IPv6 address is assigned. If that is the point, it would be
helpful if was stated explicitly.

I am no 802.16 expert, but I understand there are some scenarios
where both user and device authentication are incorporated in a
deployment scenario.  Are any of these scenarios viable for IPv6,
or are we restricted to device authentication only?  The security
implications are very different in these cases...

It might also be helpful to note that a wide range of authentication
mechanisms are in use, and that very different levels of assurance
may be achieved.  This probably be relegated to the security
considerations section.

Paragraph 2:

  IPsec is a fundamental part of IPv6.  Unlike IPv4, IPsec for IPv6 may
  be used within the global end-to-end architecture.  But, we do not
  have PKIs across organizations and IPsec is not integrated with IEEE
  802.16 network mobility management.

I assume the authors saying that end-to-end security is obviously
out of scope, but can be achieved using IPsec (with the noted practical
limitations.)  Again, if that is the case it would be helpful to be
more explicit.  What isn't stated is the degree of security that is
(or can be) achieved within the scope of the 802.16 deployment
scenarios.  One could argue that would be more appropriate in the
security considerations section, but it should probably go somewhere.

Paragraph 3:

  IEEE 802.16 network threats may be different from IPv6 and IPv6
  transition threat models [RFC4942].  It should be also discussed.

This is really important, and deserves an expanded treatment in the
security considerations section.  To paraphrase RFC 3552, the security
considerations section needs to describe how the IPv6 threat models are
impacted: Does it change the attacks that are in or out of scope,
increase susceptibility to certain attacks, or provide provide any new
protections against those attacks? 

[If these topics are covered adequately in the security considerations
of other RFCs, or in publicly available document from other SDOs,
then references are sufficient.  I didn't find them myself.]
2008-01-10
07 Tim Polk [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk
2008-01-10
07 Jari Arkko
[Ballot discuss]
This document is needed and should be published, but given that
work on it started a long time ago, it is now out …
[Ballot discuss]
This document is needed and should be published, but given that
work on it started a long time ago, it is now out of sync with
some of the actual specifications for running IP over 802.16.
Please correct the following:

> The mechanism of transporting IP traffic over IEEE 802.16 networks is
> outlined in [IEEE802.16].  [IEEE802.16] only specifies the
> convergence sublayers and the ability to transport IP over the air
> interface.  The details of IPv6 (and IPv4) operations over IEEE
> 802.16 are being discussed now in the 16ng WG.

The first sentence seems contradictory to the fact that 16ng
defines "IP over 802.16". Please drop the first sentence, and
indicate in the second sentence that the IPv6 over IPCS definition
is already an approved specification (currently in RFCEd queue);
the above text makes it sound the matter is still being discussed.

> Some architectural characteristics of IEEE 802.16 networks
> may affect the detailed operations of NDP (Neighbor Discovery
> Protocol) [RFC4861], [RFC4862].
...
> If stateless auto-configuration is used to get an IPv6 address,
> router discovery and DAD operation should be properly operated over
> IEEE 802.16 links.  In case of the shared IPv6 prefix link model, the
> DAD (Duplicate Address Detection) [RFC4861] does not adapt well to
> the 802.16 air interface as there is no native multicast support.  An
> optimization, called Relay DAD, may be required to perform DAD.
> However, in case of the point-to-point link model, DAD is easy since
> each connection to a MN is treated as a unique IPv6 link.

All the above is out of sync with what the 16NG WG eventually decided
to do. They only support the p2p link model. They will later also publish
an RFC how to support IP over Ethernet mode in 802.16, but this is
expected to operate using standard mechanisms (bridging, mld snooping,
etc).

Please align this document to the current models in 16NG.

> In this scenario, IEEE 802.16
> BSs have only MAC and PHY layers without router functionality and
> operate as a bridge.  The BS should support IPv6 classifiers as
> specified in [IEEE802.16].  However, if IPv4 stack is loaded to them
> for management and configuration purposes, it is expected that BS
> should be upgraded by implementing IPv6 stack, too.

Its not clear to me why we need to recommend upgrading the
management network in conjunction of IPv6 support. Indeed,
as the experiences from cable world show, the two can be
upgraded independently and for different reasons.

> Under fixed access model, the IEEE 802.16 BS will be deployed using
> an IP backbone rather than a proprietary backend like cellular
> systems.  Thus, many IPv6 functionalities such as [RFC4861],
> [RFC4862] will be preserved when adopting IPv6 to IEEE 802.16
> devices.

Cellular systems are these days running on IP backbones. The
word proprietary is not an appropriate characterization today,
or even during the previous generation of systems.

In any case, this document talks about 802.16, which will always
be deployed on an IP backbone. Finally, the approved 16NG IPv6
document specifies the use 4861 and 4862 as-is (well, some
timing parameters are adopted, but that is something that IP
over Foo specs can do) for 802.16.

Please delete this text.

> Fixed/Nomadic Deployment Scenarios

I am confused by the contents of this section. Is this talking about
the Ethernet CS, or the application of any 802.16 technology in
a particular business setting? I get the feeling that its the latter,
but if so, much of the content in this section is incorrect.

I would recommend talking about specific CS and deployment model.

> 2.2.2.3. IPv6 Transport
>
> Note that in this scenario Ethernet CS
> [I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate
> than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport IPv6
> packets, since the scenario needs to support plain Ethernet end-to-
> end connectivity.  However, the IPv6 CS can also be supported.  The
> MS and BS will consider the connections between the peer IP CSs at
> the MS and BS to form a point to point link.  In the Ethernet CS
> case, an Ethernet bridge may provide implementation of an
> authoritative address cache and Relay DAD.  An Authoritative address
> cache is a mapping between the IPv6 address and the MAC addresses of
> all attached MSs.
>
> The bridge builds its authoritative address cache by parsing the IPv6
> Neighbor Discovery messages used during address configuration (DAD).
> Relay DAD means that the Neighbor Solicitation message used in the
> DAD process will be relayed only to the MS which already has
> configured the solicited address as its own address (if such an MS
> exist at all).

Again, this does not seem to be in line with what the 16NG WG
recommends. Please delete.

> 2.2.2.5. Mobility
>
> No mobility functions are supported in the fixed access scenario.
> However, mobility can be supported in the radio coverage without any
> mobility protocol like WLAN technology.  Therefore, a user can access
> Internet nomadically in the coverage.

This seems incorrect in a number of ways:

- I could not parse the second sentence.

- Are you saying that the network can support mobility without
  hosts being aware (as is commonly done in WLAN)? Yes, but
  then the network needs those mobility features. Were you
  assuming they were available in the fixed deployment? If so,
  please state it.

- Obviously, any host can implement host based mobility and move
  around, even if the network does not support this in any way

> 2.3. IPv6 Multicast
>
> In IEEE 802.16 air link, downlink connections can be shared among
> multiple MSs, enabling multicast channels with multiple MSs receiving
> the same information from the BS.  Multicast and Broadcast Service
> (MBS) may be used to efficiently implement multicast.  However, it is
> not clear how to do this, as currently CID is assigned by BS, but in
> MBS it should be done at an AR and it's network scope.  It is not
> clear how this mapping will happen for MBS, so MBS discussions have
> been postponed in WiMax for now.  Note that it should be intensively
> researched later, since MBS will be one of the killer services in
> IEEE 802.16 networks.
>
> In order to support multicast services in IEEE 802.16, Multicast
> Listener Discovery (MLD) [RFC2710] must be supported between the MS
> and AR.  Also, the inter-working with IP multicast protocols and MBS
> should be considered.
>
> MBS defines Multicast and Broadcast Services, but actually, MBS seems
> to be a broadcast service, not multicasting.  MBS adheres to
> broadcast services, while traditional IP multicast schemes define
> multicast routing using a shared tree or source-specific tree to
> deliver packets efficiently.
>
> In IEEE 802.16 networks, two types of access to MBS may be supported:
> single-BS access and multi-BS access.  Therefore, these two types of
> services may be roughly mapped into Source-Specific Multicast.

This section should make it clear that multicast as already defined
works for 802.16 and IPv6. Its really very similar to how multicast
works in bridged Ethernet networks. However, the more efficient MBS
transmission has not been standardized, its integration to how IP
works has not been defined, etc. Just state that its work in progress
rather than try to specify all the above details.
2008-01-10
07 Jari Arkko
[Ballot comment]
> IPsec is a fundamental part of IPv6.  Unlike IPv4, IPsec for IPv6 may
> be used within the global end-to-end architecture.  But, …
[Ballot comment]
> IPsec is a fundamental part of IPv6.  Unlike IPv4, IPsec for IPv6 may
> be used within the global end-to-end architecture.  But, we do not
> have PKIs across organizations and IPsec is not integrated with IEEE
> 802.16 network mobility management.
>
> IEEE 802.16 network threats may be different from IPv6 and IPv6
> transition threat models [RFC4942].  It should be also discussed.

These paragraphs did not provide much information. Consider
deleting them.
2008-01-10
07 Jari Arkko
[Ballot discuss]
> The mechanism of transporting IP traffic over IEEE 802.16 networks is
> outlined in [IEEE802.16].  [IEEE802.16] only specifies the
> convergence sublayers …
[Ballot discuss]
> The mechanism of transporting IP traffic over IEEE 802.16 networks is
> outlined in [IEEE802.16].  [IEEE802.16] only specifies the
> convergence sublayers and the ability to transport IP over the air
> interface.  The details of IPv6 (and IPv4) operations over IEEE
> 802.16 are being discussed now in the 16ng WG.

The first sentence seems contradictory to the fact that 16ng
defines "IP over 802.16". Please drop the first sentence, and
indicate in the second sentence that the IPv6 over IPCS definition
is already an approved specification (currently in RFCEd queue);
the above text makes it sound the matter is still being discussed.

> Some architectural characteristics of IEEE 802.16 networks
> may affect the detailed operations of NDP (Neighbor Discovery
> Protocol) [RFC4861], [RFC4862].
...
> If stateless auto-configuration is used to get an IPv6 address,
> router discovery and DAD operation should be properly operated over
> IEEE 802.16 links.  In case of the shared IPv6 prefix link model, the
> DAD (Duplicate Address Detection) [RFC4861] does not adapt well to
> the 802.16 air interface as there is no native multicast support.  An
> optimization, called Relay DAD, may be required to perform DAD.
> However, in case of the point-to-point link model, DAD is easy since
> each connection to a MN is treated as a unique IPv6 link.

All the above is out of sync with what the 16NG WG eventually decided
to do. They only support the p2p link model. They will later also publish
an RFC how to support IP over Ethernet mode in 802.16, but this is
expected to operate using standard mechanisms (bridging, mld snooping,
etc).

Please align this document to the current models in 16NG.

> In this scenario, IEEE 802.16
> BSs have only MAC and PHY layers without router functionality and
> operate as a bridge.  The BS should support IPv6 classifiers as
> specified in [IEEE802.16].  However, if IPv4 stack is loaded to them
> for management and configuration purposes, it is expected that BS
> should be upgraded by implementing IPv6 stack, too.

Its not clear to me why we need to recommend upgrading the
management network in conjunction of IPv6 support. Indeed,
as the experiences from cable world show, the two can be
upgraded independently and for different reasons.

> Under fixed access model, the IEEE 802.16 BS will be deployed using
> an IP backbone rather than a proprietary backend like cellular
> systems.  Thus, many IPv6 functionalities such as [RFC4861],
> [RFC4862] will be preserved when adopting IPv6 to IEEE 802.16
> devices.

Cellular systems are these days running on IP backbones. The
word proprietary is not an appropriate characterization today,
or even during the previous generation of systems.

In any case, this document talks about 802.16, which will always
be deployed on an IP backbone. Finally, the approved 16NG IPv6
document specifies the use 4861 and 4862 as-is (well, some
timing parameters are adopted, but that is something that IP
over Foo specs can do) for 802.16.

Please delete this text.

> Fixed/Nomadic Deployment Scenarios

I am confused by the contents of this section. Is this talking about
the Ethernet CS, or the application of any 802.16 technology in
a particular business setting? I get the feeling that its the latter,
but if so, much of the content in this section is incorrect.

I would recommend talking about specific CS and deployment model.

> 2.2.2.3. IPv6 Transport
>
> Note that in this scenario Ethernet CS
> [I-D.ietf-16ng-ip-over-ethernet-over-802.16] may be more appropriate
> than IPv6 CS [I-D.ietf-16ng-ipv6-over-ipv6cs] to transport IPv6
> packets, since the scenario needs to support plain Ethernet end-to-
> end connectivity.  However, the IPv6 CS can also be supported.  The
> MS and BS will consider the connections between the peer IP CSs at
> the MS and BS to form a point to point link.  In the Ethernet CS
> case, an Ethernet bridge may provide implementation of an
> authoritative address cache and Relay DAD.  An Authoritative address
> cache is a mapping between the IPv6 address and the MAC addresses of
> all attached MSs.
>
> The bridge builds its authoritative address cache by parsing the IPv6
> Neighbor Discovery messages used during address configuration (DAD).
> Relay DAD means that the Neighbor Solicitation message used in the
> DAD process will be relayed only to the MS which already has
> configured the solicited address as its own address (if such an MS
> exist at all).

Again, this does not seem to be in line with what the 16NG WG
recommends. Please delete.

> 2.2.2.5. Mobility
>
> No mobility functions are supported in the fixed access scenario.
> However, mobility can be supported in the radio coverage without any
> mobility protocol like WLAN technology.  Therefore, a user can access
> Internet nomadically in the coverage.

This seems incorrect in a number of ways:

- I could not parse the second sentence.

- Are you saying that the network can support mobility without
  hosts being aware (as is commonly done in WLAN)? Yes, but
  then the network needs those mobility features. Were you
  assuming they were available in the fixed deployment? If so,
  please state it.

- Obviously, any host can implement host based mobility and move
  around, even if the network does not support this in any way

> 2.3. IPv6 Multicast
>
> In IEEE 802.16 air link, downlink connections can be shared among
> multiple MSs, enabling multicast channels with multiple MSs receiving
> the same information from the BS.  Multicast and Broadcast Service
> (MBS) may be used to efficiently implement multicast.  However, it is
> not clear how to do this, as currently CID is assigned by BS, but in
> MBS it should be done at an AR and it's network scope.  It is not
> clear how this mapping will happen for MBS, so MBS discussions have
> been postponed in WiMax for now.  Note that it should be intensively
> researched later, since MBS will be one of the killer services in
> IEEE 802.16 networks.
>
> In order to support multicast services in IEEE 802.16, Multicast
> Listener Discovery (MLD) [RFC2710] must be supported between the MS
> and AR.  Also, the inter-working with IP multicast protocols and MBS
> should be considered.
>
> MBS defines Multicast and Broadcast Services, but actually, MBS seems
> to be a broadcast service, not multicasting.  MBS adheres to
> broadcast services, while traditional IP multicast schemes define
> multicast routing using a shared tree or source-specific tree to
> deliver packets efficiently.
>
> In IEEE 802.16 networks, two types of access to MBS may be supported:
> single-BS access and multi-BS access.  Therefore, these two types of
> services may be roughly mapped into Source-Specific Multicast.

This section should make it clear that multicast as already defined
works for 802.16 and IPv6. Its really very similar to how multicast
works in bridged Ethernet networks. However, the more efficient MBS
transmission has not been standardized, its integration to how IP
works has not been defined, etc. Just state that its work in progress
rather than try to specify all the above details.
2008-01-10
07 Jari Arkko
[Ballot discuss]
> The mechanism of transporting IP traffic over IEEE 802.16 networks is
> outlined in [IEEE802.16].  [IEEE802.16] only specifies the
> convergence sublayers …
[Ballot discuss]
> The mechanism of transporting IP traffic over IEEE 802.16 networks is
> outlined in [IEEE802.16].  [IEEE802.16] only specifies the
> convergence sublayers and the ability to transport IP over the air
> interface.  The details of IPv6 (and IPv4) operations over IEEE
> 802.16 are being discussed now in the 16ng WG.

The first sentence seems contradictory to the fact that 16ng
defines "IP over 802.16". Please drop the first sentence, and
indicate in the second sentence that the IPv6 over IPCS definition
is already an approved specification (currently in RFCEd queue);
the above text makes it sound the matter is still being discussed.

> Some architectural characteristics of IEEE 802.16 networks
> may affect the detailed operations of NDP (Neighbor Discovery
> Protocol) [RFC4861], [RFC4862].
...
> If stateless auto-configuration is used to get an IPv6 address,
> router discovery and DAD operation should be properly operated over
> IEEE 802.16 links.  In case of the shared IPv6 prefix link model, the
> DAD (Duplicate Address Detection) [RFC4861] does not adapt well to
> the 802.16 air interface as there is no native multicast support.  An
> optimization, called Relay DAD, may be required to perform DAD.
> However, in case of the point-to-point link model, DAD is easy since
> each connection to a MN is treated as a unique IPv6 link.

All the above is out of sync with what the 16NG WG eventually decided
to do. They only support the p2p link model. They will later also publish
an RFC how to support IP over Ethernet mode in 802.16, but this is
expected to operate using standard mechanisms (bridging, mld snooping,
etc).

Please align this document to the current models in 16NG.

> In this scenario, IEEE 802.16
> BSs have only MAC and PHY layers without router functionality and
> operate as a bridge.  The BS should support IPv6 classifiers as
> specified in [IEEE802.16].  However, if IPv4 stack is loaded to them
> for management and configuration purposes, it is expected that BS
> should be upgraded by implementing IPv6 stack, too.

Its not clear to me why we need to recommend upgrading the
management network in conjunction of IPv6 support. Indeed,
as the experiences from cable world show, the two can be
upgraded independently and for different reasons.

> Under fixed access model, the IEEE 802.16 BS will be deployed using
> an IP backbone rather than a proprietary backend like cellular
> systems.  Thus, many IPv6 functionalities such as [RFC4861],
> [RFC4862] will be preserved when adopting IPv6 to IEEE 802.16
> devices.

Cellular systems are these days running on IP backbones. The
word proprietary is not an appropriate characterization today,
or even during the previous generation of systems.

In any case, this document talks about 802.16, which will always
be deployed on an IP backbone. Finally, the approved 16NG IPv6
document specifies the use 4861 and 4862 as-is (well, some
timing parameters are adopted, but that is something that IP
over Foo specs can do) for 802.16.

Please delete this text.
2008-01-10
07 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2008-01-10
07 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-01-09
07 Russ Housley
[Ballot discuss]
The authors have agreed to make changes based on the Gen-ART Review
  by Brian Carpenter.  A revisee document has not been posted …
[Ballot discuss]
The authors have agreed to make changes based on the Gen-ART Review
  by Brian Carpenter.  A revisee document has not been posted yet.  The
  review text can be found at:

    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-v6ops-802-16-deployment-scenarios-06-carpenter.txt
2008-01-09
07 Russ Housley [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley
2008-01-08
07 Amanda Baber IANA Evaluation comments:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.
2008-01-08
07 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2008-01-07
07 Dan Romascanu
[Ballot discuss]
From Section 2.6:

  IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
  network elements are implemented dual …
[Ballot discuss]
From Section 2.6:

  IPv6 based IEEE 802.16 networks can be managed by IPv4 or IPv6 when
  network elements are implemented dual stack.  For example, network
  management systems (NMS) can send SNMP messages by IPv4 with IPv6
  related object identifiers.  Also, an NMS can use IPv6 for SNMP
  requests and responses including IPv4 related OID.

The terminology that is being used here is slightly flawn, there is no such thing as IPv4 or IPv6 related OIDs. OIDs in MIBs point to managed objects which most of them are independent of either IPv4 or IPv6 and only a few of them (the objects not the OIDs) are IPv4 or IPv6 related. What I believe the authors mean is that all objects in all MIB modules may be accessed equally if IPv4 or IPv6 is used to carry the SNMP messages.
2008-01-07
07 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu
2008-01-03
07 Samuel Weiler Request for Telechat review by SECDIR is assigned to Julien Laganier
2008-01-03
07 Samuel Weiler Request for Telechat review by SECDIR is assigned to Julien Laganier
2007-12-27
07 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2007-12-27
07 Ron Bonica Ballot has been issued by Ron Bonica
2007-12-27
07 Ron Bonica Created "Approve" ballot
2007-12-27
07 (System) Ballot writeup text was added
2007-12-27
07 (System) Last call text was added
2007-12-27
07 (System) Ballot approval text was added
2007-12-27
07 Ron Bonica Placed on agenda for telechat - 2008-01-10 by Ron Bonica
2007-12-27
07 Ron Bonica State Changes to IESG Evaluation from Waiting for Writeup by Ron Bonica
2007-12-27
07 Ron Bonica State Changes to Waiting for Writeup from AD is watching by Ron Bonica
2007-12-21
06 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-06.txt
2007-12-19
07 (System) State Changes to AD is watching from Dead by system
2007-12-18
05 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-05.txt
2007-12-14
07 (System) State Changes to Dead from AD is watching::Revised ID Needed by system
2007-12-14
07 (System) Document has expired
2007-12-13
07 Ron Bonica State Changes to AD is watching::Revised ID Needed from Publication Requested by Ron Bonica
2007-06-21
07 Dinara Suleymanova
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, …
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

I am the shepherd for this document. I have read this version, and
believe that it is ready for publication as an RFC.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

I believe that it has had adequate review. It was originally posted
in March 2006 and discussed in that meeting of the working group, and
resubmitted as a working group document in May of that year. It was
proposed as an extension of the v6ops broadband work, specifically
addressing 802.16/Wimax networks. There were various issues raised
and dealt with during subsequent revisions. Comment on the mailing
list came from Jonne Soininen, Brian Carpenter, Eric Klein, Bruno
Miguel Sousa (speaking for the 16NG working group in a solicited
review), Jim Bound, and JinHyeock Choi. A review was also solicited
from mip6; I believe that the response was directly to the authors,
as I have no copy of it. The document was last-called in January 2007
and sent to the Area Director, David Kessens, in February, who
responded asking whether we had received any comments to the effect
that the document was needed. In a re-last-call in April, undertaken
to solicit additional review and address the AD's concern, the
comments both in the meeting and on the list were supportive, and
specifically Jim Bound stated that he considered the draft to be
helpful in 802.16 deployment.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

Given that review has already occurred in v6ops, mip6, and 16ng, I
don't see a need for further review.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the
document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

If such concerns exist, they have not been raised to me.

Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No IPR disclosure was discussed in the working group. I looked at
https://datatracker.ietf.org/public/ipr_search.cgi a moment ago,
which reported:
> Internal Server Error
>
> The server encountered an internal error or misconfiguration and
> was unable to complete your request.
>
> Please contact the server administrator, webmaster@ietf.org and
> inform them of the time the error occurred, and anything you might
> have done that may have caused the error.
>
> More information about this error may be available in the server
> error log.
(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

IPv6 Operations tends to be a group in which projects are done by
small groups with relevant expertise and reviewed by others. The
sense I have had in meetings and on the list has been that there is
general support. That said, the primary cognitive input has come from
the authors and a few others, listed above.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director.
(It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No such conflicts have been brought to my attention.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the
document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

yes. I note the iddnits report here. The "intended status" of the
document is "informational, not "proposed standard" as the tool
presumed, and the "unused reference" was in fact used but broken
across a line ending. The normative reference to RFC 4779 is a
spurious note given that both 4779 and this document are informative.
The other checklist items were not issues with this document.

The RFC Editor will note that the authors speak English as a second
language, which will necessitate a certain level of copy editing. I
find the document quite readable even so, so this should not be onerous.

> idnits 2.04.09
> - The downloaded file seems to be corrupt, proceeding with outdated
> information.)
>
> tmp/draft-ietf-v6ops-802-16-deployment-scenarios-04.txt:
> - Failure fetching the file, proceeding without it.)
>
> Checking boilerplate required by RFC 3978 and 3979, updated by
> RFC 4748:
>
> ----------------------------------------------------------------------
> ------
>
> No issues found here.
>
> Checking nits according to http://www.ietf.org/ietf/1id-
> guidelines.txt:
>
> ----------------------------------------------------------------------
> ------
>
> == No 'Intended status' indicated for this document; assuming
> Proposed
> Standard
>
>
> Checking nits according to http://www.ietf.org/ID-Checklist.html:
>
> ----------------------------------------------------------------------
> ------
>
> No issues found here.
>
> Miscellaneous warnings:
>
> ----------------------------------------------------------------------
> ------
>
> No issues found here.
>
> Checking references for intended status: Proposed Standard
>
> ----------------------------------------------------------------------
> ------
>
> (See RFC 3967 for information about using normative references to
> lower-maturity documents in RFCs)
> == Unused Reference: 'I-D.ietf-mipshop-fmipv6-rfc4068bis' is
> defined on
> line 657, but no explicit reference was found in the
> text
> '[I-D.ietf-mipshop-fmipv6-rfc4068bis] Koodli, R., "Fast
> Handovers for...'
>
> ** Downref: Normative reference to an Informational RFC: RFC 4779
>
>
> Summary: 1 error (**), 2 warnings (==), 0 comments (--).
>
> ----------------------------------------------------------------------
> ----------

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents
that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative
references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes it has divided its references. The "normative" references are all
to RFCs, and therefore have no publication issue.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document?

The document creates no registries, and says as much in its IANA
considerations section.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no such sections.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document provides a detailed description of IPv6 deployment and
integration methods and scenarios in wireless broadband access
networks in coexistence with deployed IPv4 services. It discusses the
main components of IPv6 IEEE 802.16 access networks, their
differences from IPv4 IEEE 802.16 networks, and how IPv6 is deployed
and integrated in each of the IEEE 802.16 technologies.

Working Group Summary

The document was reviewed by participants from both the IPv6
Operations WG and the 16NG Working Group. No lingering concerns
remained as it completed its review.

Document Quality

As described in the IPv6 Operations charter, this document's purpose
was to review the issues that might arise in deploying IPv6 in an
IEEE 802.16 network. The document uses "IEEE 802.16" as essentially
equivalent to "Wimax", although one could argue that they differ. It
builds on the structure and considerations of RFC 4779, which is a
more general document looking at IPv6 deployment in broadband
networks in general. It notes issues such as the fact that 802.16 QoS
definitions differ from and have to be operationally mapped to IP
Differentiated Services concepts, and specifically comments on the
use of IPv6 Multicast, QoS, Security, and Network Management in IEEE
802.16 fixed and mobile access networks.

Personnel

The Document Shepherd is Fred Baker. The Responsible AD is Ron Bonica.
2007-06-21
07 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2007-04-27
04 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-04.txt
2007-02-16
03 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-03.txt
2007-01-17
02 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-02.txt
2006-10-02
01 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-01.txt
2006-05-30
00 (System) New version available: draft-ietf-v6ops-802-16-deployment-scenarios-00.txt