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

From: The IESG <[email-masked]>
Date: Fri, 25 Jan 2002 17:16:05 -0500

The IESG has received a request from the Multiparty Multimedia Session
Control Working Group to consider Support for IPv6 in SDP
<draft-ietf-mmusic-sdp-ipv6-01.txt> as a Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by February 8, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Pekka Savola <[email-masked]>
Date: Sun, 27 Jan 2002 19:12:59 +0200 (EET)

> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt

In the draft:
--8<--
5. Example SDP description with IPv6 addresses

   The following is an example SDP description using the above ABNF
   for IPv6 addresses. In particular, the origin, URI, and connection
   fields contain IPv6 addresses. The URI contains an IPv4 compatible
   IPv6 address.

   v=0
   o=nasa1 971731711378798081 0 IN IP6 2201:056D::112E:144A:1E24
   s=(Almost) live video feed from Mars-II sattelite
   u=http://[::FFFF:10.2.12.126]/marsII
   p=+1 713 555 1234
   c=IN IP6 FF00:03AD::7F2E:172A:1E24
   t=3338481189 3370017201
   m=audio 6000 RTP/AVP 2
   a=rtpmap:2 G726-32/8000
   m=video 6024 RTP/AVP 107
   a=rtpmap:107 H263-1998/90000
--8<--

There are several issues with this:

1) I don't think it's good practise to use these addresses in an example, 
I'd rather use:
 - 3FFE:FFFF::112E:144A:1E24 (as 2201 TLA hasn't been assigned yet and we 
don't know if there would be some special meaning for it in the future)
 - FF0E:03AD::7F2E:172A:1E24 (global, not reserved scope)

2) s/The URI contains an IPv4 compatible IPv6 address/The URI contains an 
IPv4-mapped address/ in the header, or change u=.

3) IMO, it's a bit questionable to use IPv4-mapped addresses like this
anyway. IPv4-mapped addresses should only be used (apart from e.g. SIIT
definition) as a node's internal representation for IPv4 address; for
better compatibility, the node should use:

   u=http://10.2.12.126/marsII

(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)

Also:
--8<--
   IP6-multicast =       hexpart [ ":" IP4-multicast ]  
                         "/" ttl [ "/" integer ] 
                         ; IPv6 address starting with FF00
--8<--

1) 'ttl' is not defined anywhere? (rather obvious though); (_TTL_ is not 
defined in IPv6 anyway, though.)

2) IPv6-multicast address does not need to start with FF00; anything 
beginning with FF is syntactically ok.

3) The full list of ABNF notations could be split to "normative" and
"informative" (e.g. of the latter, in this context, IP4-address, b1, b4,
perhaps others), but that's a matter of opinion/clarity I guess.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords