Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks
draft-ietf-ipdvb-ar-06

[Ballot discuss]
The abstract and introduction should be very
clear that this document is only a survey

> 5.5 DHCP Tuning

This section does not talk about what happens
to DHCP when the link is not bidirectional.

No change in -06.

> This document has reviewed the status of these
> current address resolution mechanisms in MPEG-2
> transmission networks and defined their usage. 

It is fine to review existing mechanisms. But
I am concerned that this document does not
really in detail "define usage". I'm not
sure I could implement anything based on this,
though it is possible that the references
provide additional information.

No change in -06.

[Ballot discuss]
The abstract and introduction should be very
clear that this document is only a survey
of existing mechanisms, NOT a specification
of how to do address resolution over DVB.
This is reflected in the charter, but its
not very clear in the document itself.

(This item is from Margaret Wasserman's review)

> +-------------------------------+--------+----------------------+
> |                              | PDU    |L2 Frame Header Fields|
> | L2 Encapsulation              |overhead+----------------------+
> |                              |[bytes] |src mac|dst mac| type |
> +-------------------------------+--------+-------+-------+------+
> |6.1 ULE without dst MAC address| 8      |  -  |  -    | x    |
> |6.2 ULE with dst MAC address  | 14    |  -  |  x    | x    |
> |6.3 MPE without LLC/SNAP      | 16    |  -  |  x    | -    |
> |6.4 MPE with LLC/SNAP          | 24    |  -  |  x    | x    |
> |6.5 ULE with Bridging extension| 22    |  x  |  x    | x    |
> |6.6 ULE with Bridging & NPA    | 28    |  x  |  x    | x    |
> |6.7 MPE+LLC/SNAP+Bridging      | 38    |  x  |  x    | x    |
> +-------------------------------+--------+-------+-------+------+

Considerations from draft-iab-link-encaps-05 apply.
The use of different address resolution mechanisms
adds new issues. The draft should make it clear
what the interoperability implications of this
situation are, and, hopefully, talk about how
the involved nodes can determine what to do.

> Methods also exist to assign IP addresses to Receivers within a
> network (e.g. DHCP [RFC2131], DHC [RFC3736]).

I think you mean stateless autoconfiguration [RFC2461], DHCP [RFC2131],
DHCPv6 [RFC3315], stateless DHCPv6 [RFC3736].

> A method to represent IPv4/IPv6 AR information (including
> security associations to authenticate the AR information that
> will prevent address masquerading [RFC3756]). 

s/associations/mechanisms/ would be better, I think.

> The goal of this multicast address resolution is the association of
> an IPv4 or IPv6 multicast address with a specific TS Logical Channel
> and the corresponding TS Multiplex.

From what I understand a TS Multiplex could be, e.g., a
particular transmission area. If so, we do not want to
limit the reception of a multicast group to one area only.
Shouldn't this be an association to one or more TS LCs
and TS-MUXes?

> SEND also does not impact the IPsec architecture and
> implementations, and provides improved support for security
> decisions based on application state. This allows co-existence of
> SEND and insecure ND on the same link. 

The first sentence is confusing. SEND does not deal
with applications, but the way SEND was constructed
allows it to take advantage of ND-related state
to make security decisions. Suggested rewrite:

SEND also does not require the configuration of
per-host keys and can co-exist with the use of
both SEND and insecure ND on the same link.

> 5.5 DHCP Tuning

This section does not talk about what happens
to DHCP when the link is not bidirectional.

> The IPv6 ND protocol is supported. The protocol uses a block of IPv6
> multicast addresses, which need to be carried by the L2 network. The
> protocol does not require specification of a MAC source address,
> although this is required for a node to participate in Duplicate
> Address Detection (DAD) [RFC2462].

Really? I am not sure this is the case.

> Since there is no MAC/NPA address in the SNDU, ARP and
> NDP are not required. 

ND for address resolution is not needed, but it
may still be needed for DAD or NUD.

> 6.1 ULE without a destination MAC/NPA address (D=1)

The other sections except this talk about the
need to support multicast. But it seems that
for ND to work multicast will be required for
the RAs to reach the hosts, as well as for
DAD.

> This document has reviewed the status of these
> current address resolution mechanisms in MPEG-2
> transmission networks and defined their usage. 

It is fine to review existing mechanisms. But
I am concerned that this document does not
really in detail "define usage". I'm not
sure I could implement anything based on this,
though it is possible that the references
provide additional information.

[Ballot discuss]
> +-------------------------------+--------+----------------------+
> |                              | PDU    |L2 Frame Header Fields|
> | L2 Encapsulation              |overhead+----------------------+
> |                              |[bytes] |src mac|dst mac| type |
> +-------------------------------+--------+-------+-------+------+
> |6.1 ULE without dst MAC address| 8      |  -  |  -    | x    |
> |6.2 ULE with dst MAC address  | 14    |  -  |  x    | x    |
> |6.3 MPE without LLC/SNAP      | 16    |  -  |  x    | -    |
> |6.4 MPE with LLC/SNAP          | 24    |  -  |  x    | x    |
> |6.5 ULE with Bridging extension| 22    |  x  |  x    | x    |
> |6.6 ULE with Bridging & NPA    | 28    |  x  |  x    | x    |
> |6.7 MPE+LLC/SNAP+Bridging      | 38    |  x  |  x    | x    |
> +-------------------------------+--------+-------+-------+------+

Considerations from draft-iab-link-encaps-05 apply.
The use of different address resolution mechanisms
adds new issues. The draft should make it clear
what the interoperability implications of this
situation are, and, hopefully, talk about how
the involved nodes can determine what to do.

> Methods also exist to assign IP addresses to Receivers within a
> network (e.g. DHCP [RFC2131], DHC [RFC3736]).

I think you mean stateless autoconfiguration [RFC2461], DHCP [RFC2131],
DHCPv6 [RFC3315], stateless DHCPv6 [RFC3736].

> A method to represent IPv4/IPv6 AR information (including
> security associations to authenticate the AR information that
> will prevent address masquerading [RFC3756]). 

s/associations/mechanisms/ would be better, I think.

> The goal of this multicast address resolution is the association of
> an IPv4 or IPv6 multicast address with a specific TS Logical Channel
> and the corresponding TS Multiplex.

From what I understand a TS Multiplex could be, e.g., a
particular transmission area. If so, we do not want to
limit the reception of a multicast group to one area only.
Shouldn't this be an association to one or more TS LCs
and TS-MUXes?

> SEND also does not impact the IPsec architecture and
> implementations, and provides improved support for security
> decisions based on application state. This allows co-existence of
> SEND and insecure ND on the same link. 

The first sentence is confusing. SEND does not deal
with applications, but the way SEND was constructed
allows it to take advantage of ND-related state
to make security decisions. Suggested rewrite:

SEND also does not require the configuration of
per-host keys and can co-exist with the use of
both SEND and insecure ND on the same link.

> 5.5 DHCP Tuning

This section does not talk about what happens
to DHCP when the link is not bidirectional.

> The IPv6 ND protocol is supported. The protocol uses a block of IPv6
> multicast addresses, which need to be carried by the L2 network. The
> protocol does not require specification of a MAC source address,
> although this is required for a node to participate in Duplicate
> Address Detection (DAD) [RFC2462].

Really? I am not sure this is the case.

> Since there is no MAC/NPA address in the SNDU, ARP and
> NDP are not required. 

ND for address resolution is not needed, but it
may still be needed for DAD or NUD.

> 6.1 ULE without a destination MAC/NPA address (D=1)

The other sections except this talk about the
need to support multicast. But it seems that
for ND to work multicast will be required for
the RAs to reach the hosts, as well as for
DAD.

> This document has reviewed the status of these
> current address resolution mechanisms in MPEG-2
> transmission networks and defined their usage. 

It is fine to review existing mechanisms. But
I am concerned that this document does not
really in detail "define usage". I'm not
sure I could implement anything based on this,
though it is possible that the references
provide additional information.

[Ballot discuss]
> Methods also exist to assign IP addresses to Receivers within a
> network (e.g. DHCP [RFC2131], DHC [RFC3736]).

I think you mean stateless autoconfiguration [RFC2461], DHCP [RFC2131],
DHCPv6 [RFC3315], Stateless DHCPv6 [RFC3736].

> A method to represent IPv4/IPv6 AR information (including
> security associations to authenticate the AR information that
> will prevent address masquerading [RFC3756]). 

s/associations/mechanisms/ would be better, I think.

> The goal of this multicast address resolution is the association of
> an IPv4 or IPv6 multicast address with a specific TS Logical Channel
> and the corresponding TS Multiplex.

From what I understand a TS Multiplex could be, e.g., a
particular transmission area. If so, we do not want to
limit the reception of a multicast group to one area only.
Shouldn't this be an association to one or more TS LCs
and TS-MUXes?

> SEND also does not impact the IPsec architecture and
> implementations, and provides improved support for security
> decisions based on application state. This allows co-existence of
> SEND and insecure ND on the same link. 

The first sentence is confusing. SEND does not deal
with applications, but the way SEND was constructed
allows it to take advantage of ND-related state
to make security decisions. Suggested rewrite:

SEND also does not require the configuration of
per-host keys and can co-exist with the use of
both SEND and insecure ND on the same link.

> 5.5 DHCP Tuning

This section does not talk about what happens
to DHCP when the link is not bidirectional.

> The IPv6 ND protocol is supported. The protocol uses a block of IPv6
> multicast addresses, which need to be carried by the L2 network. The
> protocol does not require specification of a MAC source address,
> although this is required for a node to participate in Duplicate
> Address Detection (DAD) [RFC2462].

Really? I am not sure this is the case.

(TO BE CONTINUED...)

PROTO Write-up

1) Have the chairs personally reviewed this version of the ID and do
they believe this ID is sufficiently baked to forward to the IESG
for publication?

Yes.

2) Has the document had adequate review from both key WG members and
key non-WG members? Do you have any concerns about the depth or
breadth of the reviews that have been performed?

The document is a result of many different contributions, and many edit
cycles, and is now considered ready for publication.

3) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No.

4) Do you have any specific concerns/issues with this document that
you believe the ADs and/or IESG should be aware of? For example,
perhaps you are uncomfortable with certain parts of the document,
or whether there really is a need for it, etc., but at the same
time these issues have been discussed in the WG and the WG has
indicated it wishes to advance the document anyway.

No. Apart from capturing the use of existing mechanisms, it was
anticipated that the WG would use this as a basis for definition of a
new IP-based method common to all scenarios. There continues to be
discussion of such work, although there is as yet no clear single method
that could be progressed along the Standards-Track.

The document as stands comprises a useful guide to the issues and
potential solutions, applicable to a wide range of MPEG-2-based networks.



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

The document has received feedback from many in the WG. At several
stages Martin Striemerling provided a detailed review, which assisted
the WG in capturing many areas of weakness in the early document. All
issues raised have been addressed in this rev.

6) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize what are they upset about.

No.

7) Have the chairs verified that the document adheres to _all_ of the
ID nits?

Yes.

8) Please provide a draft write-up to appear in the ballot and
approval announcement:

- Technical Summary

This document describes the process of binding/associating IPv4/IPv6
addresses with MPEG-2 Transport Streams (TS). This procedure is
known as Address Resolution (AR), or Neighbour Discovery (ND). Such
address resolution complements the higher layer resource discovery
tools that are used to advertise IP sessions.

In MPEG-2 Networks, an IP address must be associated with a Packet
ID (PID) value and a specific Transmission Multiplex. The document
reviews current methods appropriate to a range of technologies (DVB,
ATSC, DOCSIS, and variants). It also describes the interaction with
well-known protocols for address management including DHCP, ARP, and
the ND protocol, and provides guidance on usage.

- Working Group Summary

This document is a chartered item of the ipdvb WG. The document provides
a description of the mechanisms required to provide AR within an
MPEG-2 network, and how to achieve operational networks using
IETF-defined methods that work with large numbers of receivers and in
particular can accommodate the large(r) link delay. The charter item
states:

"Provide an Informational RFC describing a framework for unicast and
multicast address resolution over MPEG-2 transmission networks. The
document will describe options for the address resolution process,
relating these to appropriate usage scenarios and suggesting
appropriate protocol mechanisms for both the existing Multi-Protocol
Encapsulation (MPE) and the efficient encapsulation (2). Consideration
will be paid to existing standards, and the cases for IPv6 and IPv4
will be described."

The document also provides specific guidance for UDLR when used with DVB
networks and has references the specific case of DOCSIS. The advice and
issues described may also be applicable to other L2 networks.


- Protocol Quality

The document does not define a new protocol. It describes issues and
appropriate tuning for deployment of IETF and non-IETF protocols to
deliver an IP service over MPEG-2 based networks.

---

The questionnaire and writeup is sent to the ADs and
iesg-secretary@ietf.org with a request to publish the document.

The publication request SHOULD also indicate which chair will be
shepherding the document, so that this can be entered into the ID
Tracker [IDTRACKER]. In addition to making life easier for the
ADs, this lets the IETF chair know where to send Gen-ART [GEN-ART]
reviews.

+++

WG Internet Draft: draft-ietf-ipdvb-ar-05.txt
Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks

ipdvb WG Chair: G Fairhurst
WG Shepherd: G Fairhurst