Skip to main content

Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks
RFC 4947

Revision differences

Document history

Date Rev. By Action
2018-12-20
06 (System)
Received changes through RFC Editor sync (changed abstract to 'This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure …
Received changes through RFC Editor sync (changed abstract to '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 Neighbor 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. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol. This memo provides information for the Internet community.')
2015-10-14
06 (System) Notify list changed from ipdvb-chairs@ietf.org to (None)
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Jari Arkko
2010-11-22
06 David Harrington Assignment of request for Last Call review by SECDIR to David Harrington was rejected
2007-08-10
06 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-08-10
06 Amy Vezza [Note]: 'RFC 4947' added by Amy Vezza
2007-07-18
06 (System) RFC published
2007-04-04
06 (System) IANA Action state changed to No IC from In Progress
2007-04-04
06 (System) IANA Action state changed to In Progress
2007-04-02
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-04-02
06 Amy Vezza IESG state changed to Approved-announcement sent
2007-04-02
06 Amy Vezza IESG has approved the document
2007-04-02
06 Amy Vezza Closed "Approve" ballot
2007-04-02
06 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2007-03-23
06 Jari Arkko RFC Editor notes cleared my final concern (worked with Gorry to come up with the text).
2007-03-23
06 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko
2007-03-19
06 Jari Arkko met with chairs today and agreed on edits to make this move forward.
2007-03-17
06 Jari Arkko
[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 …
[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.
2007-03-15
06 Mark Townsley [Note]: 'Chairs believe new version meets DISCUSS concerns from Jari. Waiting on Jari to clear.' added by Mark Townsley
2007-03-15
06 Mark Townsley [Note]: 'Chairs believe new version meets DISCUSS concerns from Jari.' added by Mark Townsley
2007-03-02
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-03-02
06 (System) New version available: draft-ietf-ipdvb-ar-06.txt
2006-11-17
06 (System) Removed from agenda for telechat - 2006-11-16
2006-11-16
06 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-11-16
06 Jari Arkko
[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 …
[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.
2006-11-16
06 Jari Arkko
[Ballot discuss]
> +-------------------------------+--------+----------------------+
> |                              | PDU    |L2 Frame …
[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.
2006-11-16
06 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-11-16
06 Jari Arkko
[Ballot discuss]
> Methods also exist to assign IP addresses to Receivers within a
> network (e.g. DHCP [RFC2131], DHC [RFC3736]). …
[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...)
2006-11-16
06 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko
2006-11-15
06 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2006-11-15
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-11-15
06 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2006-11-15
06 Amy Vezza State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Amy Vezza
2006-11-15
06 Yoshiko Fong IANA Last Call Comment:


As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.
2006-11-14
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-11-14
06 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2006-11-13
06 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-11-08
06 Samuel Weiler Assignment of request for Last Call review by SECDIR to Ran Canetti was rejected
2006-11-08
06 (System) Request for Last Call review by SECDIR is assigned to Ran Canetti
2006-11-08
06 (System) Request for Last Call review by SECDIR is assigned to David Harrington
2006-11-08
06 (System) Request for Last Call review by SECDIR is assigned to David Harrington
2006-11-08
06 (System) Request for Last Call review by SECDIR is assigned to Ran Canetti
2006-10-30
06 Amy Vezza Last call sent
2006-10-30
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-10-30
06 Mark Townsley Placed on agenda for telechat - 2006-11-16 by Mark Townsley
2006-10-30
06 Mark Townsley State Changes to Last Call Requested from Publication Requested by Mark Townsley
2006-10-30
06 Mark Townsley Last Call was requested by Mark Townsley
2006-10-30
06 Mark Townsley [Ballot Position Update] New position, Yes, has been recorded for Mark Townsley
2006-10-30
06 Mark Townsley Ballot has been issued by Mark Townsley
2006-10-30
06 Mark Townsley Created "Approve" ballot
2006-10-30
06 (System) Ballot writeup text was added
2006-10-30
06 (System) Last call text was added
2006-10-30
06 (System) Ballot approval text was added
2006-09-25
06 Dinara Suleymanova
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 …
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
2006-09-25
06 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-08-24
05 (System) New version available: draft-ietf-ipdvb-ar-05.txt
2006-06-22
04 (System) New version available: draft-ietf-ipdvb-ar-04.txt
2006-05-03
03 (System) New version available: draft-ietf-ipdvb-ar-03.txt
2006-02-09
02 (System) New version available: draft-ietf-ipdvb-ar-02.txt
2005-09-14
01 (System) New version available: draft-ietf-ipdvb-ar-01.txt
2005-06-16
00 (System) New version available: draft-ietf-ipdvb-ar-00.txt