Subject: Re: [MMUSIC] RE: Last Call: Support for IPv6 in SDP to Proposed Standard

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 31 Jan 2002 22:35:36 +0200

Hi,

The draft defines how to express IPv6 addresses in SDP. How you use this
format is up to the application (i.e., outside the scope of this draft).
Remember that SDP is used by many protocols (SIP, SAP, MGCP, RTSP). 

A good example is SIP. An MMUSIC document defines how to use SDP in
conjunction with SIP. 3G systems, for instance, will use SDP and IPv6
together. They will define how to use this format when establishing a
session. They will explicitly say which address you have to put in the c
line (IPv4, or IPv6 or maybe FQDN).

Therefore, comments about the actual format are very welcome. Other
comments are interesting for other documents, but I do not think the
IESG has to be involved in such a discussion until those documents are
done. 

Regards,

Gonzalo

"Hesham Soliman (ERA)" wrote:
> 
> I think Gonzalo already answered this.
> Further clarifications are below, but
> we might be getting off-topic for this draft.
> 
>    > (this way the receiving IPv6 node can decide the mechanism
>   > >   > to reach the
>   > >   > IPv4-address; that is, if u= can contain either IPv4 or
>   > >   > IPv6 address)
>   >
>   > I'll restate this: this depends on the definition of u=.
>   >
>   > If 'u' can have:
>   >  1) only IPv6 addresses, using mapped address is fine
>   >  2) either iPv6 or IPv4 address, IMO IPv4 should be used
>   > when _sending_
>   > the packet
> 
> => See below.
> 
>   >
>   > We're arguing about point 2).  My point is that if address
>   > can be either,
>   > some nodes [a dual stack] can receive values with u=[ipv4]
>   > _anyway_, and
>   > must be able to cope with them.
> 
> => I was not conerned about dual stacked nodes,
> they'll obviously understand. Some systems
> require IPv6 only though, Others might prefer
> to run IPv6 only for simplicity, so you shouldn't
> assume dual stacks all the time.
> 
> Hesham
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Pessi <[email-masked]>
Date: 04 Feb 2002 17:53:22 +0200

Hello Gonzales,

>IESG has to be involved in such a discussion until those documents are

	Would it be impossible (or too late) to align your spec with the
	updated format in sdp-new-04? It fixes the errors in your ABNF
	and it is mostly consistent with the syntax in RFC 2327.

	I have cut and pasted relevant ABNF from sdp-new-04 and RFC 2327
	(FQDN and TTL are from old SDP) below. It is not strictly
	compatible with RFC 2327 as it fixes a bug with
	multicast-address rule (which could have more than 4 octets in
	RFC 2327):

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
3. Syntax

   RFC2373 [1] gives an ABNF for the text representation of IPv6 addresses in 
   Appendix B. RFC2732 [3] covers the text representation of IPv6 addresses 
   when used within a URL. Using the ABNF described in these documents, the 
   following updated ABNF for SDP is proposed.

   connection-address =  multicast-address
                         | addr

   multicast-address =   addr "/" ttl [ "/" integer ]
        ;IPv4 multicast addresses must be in the range
        ;224.0.0.0 to 239.255.255.255
        ;IPv6 multicast addresses must begin with the byte FF
        ;or include an IPv4 multicast address

   ttl =                 decimal-uchar

   addr =                FQDN | unicast-address

   unicast-address =     IP4-address | IP6-address

   FQDN =                4*(alpha-numeric|"-"|".")
                         ;fully qualified domain name as specified in RFC1035

   ; IP4-address, IP6-address: From RFC 2373
   IP6-address =         hexpart [ ":" IP4-address ]
   IP4-address =         1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

   hexpart =             hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
   hexseq =              hex4 *( ":" hex4)
   hex4 =                1*4HEXDIG

   uri =                 URI-reference ; defined in RFC2396/2732

   ; decimal-uchar, integer, and alpha-numeric are defined in RFC2327

-->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8--

	You could also discuss how TTL should be used with IPv6
	addresses. While TTL is nice thing and makes it easy to
    	recognize multicast addresses, it is not compatible with RFC2327
    	syntax. So, I propose something like following:

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
4.2 IPv6 and Multicast Addresses

    The IPv6 multicast addresses have the following format:

   |   8    |  4 |  4 |                  112 bits                   |
   +------ -+----+----+---------------------------------------------+
   |11111111|flgs|scop|                  group ID                   |
   +--------+----+----+---------------------------------------------+

    A 8-bit prefix of all ones at the start of the address identitifies
    a multicast address. The text representation of the IPv6 multicast
    addresses begins always with a four-digit hex segment starting with
    "FF".

    Following the prefix are three reserved bits, initialized to zero,
    and a flag indicating how the address has been assigned. In text
    representation, the third hex-digit indicates if the multicast
    address is well-known (even digit) or transient (odd digit).

    The following four bits, scop, indicates the scope of the multicast
    address. The scop is the fourth hex-digit in the text
    representation. There is no TTL in IPv6, but the scope and group ID
    together identifies the multicast group.

    For multicast addresses mapped uniquely to IEEE 802 MAC addresses,
    the next 80 bits or 20 hex digits are reserved and must be zero. The
    last 32 bits identitifies the group within given scope.

   |   8    |  4 |  4 |          80 bits          |     32 bits     |
   +------ -+----+----+---------------------------+-----------------+
   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
   +--------+----+----+---------------------------+-----------------+

4.2.1 Using TTL with IPv6 Multicast Address

    Conferences using an IPv6 multicast connection address SHOULD also
    have a time to live (TTL) value present in addition to the multicast
    address. The TTL and the IPv4 address together define the scope with
    which multicast packets sent in this conference will be sent. When
    an IPv4-compatible-IPv6 or IPv4-mapped-IPv6 address is used, TTL
    value MUST be in the range 0-255.

    When an IPv6 multicast connection address is used, a TTL value of 0
    SHOULD is included.

    The TTL for the session is appended to the address using a slash as
    a separator.  Examples are:

         c=IN IP6 FF1E::172A:1E24/0

         c=IN IP6 ::233.42.30.36/16
-->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8--

						Pekka