idnits 2.17.1 draft-olson-sdp-ipv6-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 8009 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '4' is defined on line 175, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 179, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2373 (ref. '1') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2327 (ref. '2') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2732 (ref. '3') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sean Olson 2 Internet draft Adam Roach 3 Gonzalo Camarillo 4 Ericsson 5 December 2001 6 Expires May 2002 7 9 Support for IPv6 in SDP 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes the use of IPv6 addresses [1] in conjunction 33 with the Session Description Protocol (SDP) [2]. Specifically, this 34 document clarifies existing text in SDP with regards to the syntax of 35 IPv6 addresses. 37 1. Introduction 39 SDP is intended for describing multimedia sessions for the purposes of 40 session announcement, session invitation, and other forms of multimedia 41 session initiation. It is a text format description that provides 42 many details of a multimedia session including: the originator of the 43 session, a URL related to the session, the connection address for the 44 session media(s), and optional attributes for the session media(s). 45 Each of these pieces of information may involve one or more IPv6 46 addresses. The ABNF for IP addresses in SDP currently leaves the syntax 47 for IPv6 addresses undefined. This Internet-Draft attempts to complete 48 the ABNF to include IPv6 addresses. 50 Accordingly, the address type "IP6" indicating an IPv6 address, should 51 be allowed in the connection field, "c=", of the SDP. The ABNF already 52 reflects this, though the "Connection Data" text under section 6 of 53 RFC2328 currently only defines the "IP4" address type. 55 2. Terminology 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 58 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 59 "OPTIONAL" in this document are to be interpreted as described in 60 RFC 2119. 62 3. Syntax 64 RFC2373 [1] gives an ABNF for the text representation of IPv6 addresses in 65 Appendix B. RFC2732 [3] covers the text representation of IPv6 addresses 66 when used within a URL. Using the ABNF described in these documents, the 67 following updated ABNF for SDP is proposed. 69 uri = ; defined in RFC1630 and RFC2732 71 multicast-address = IP4-multicast | IP6-multicast 73 IP4-multicast = m1 3*( "." decimal-uchar ) "/" ttl [ "/" integer ] 74 ; IPv4 multicast addresses may be in the range 75 ; 224.0.0.0 to 239.255.255.255 77 m1 = ("22" ("4"|"5"|"6"|"7"|"8"|"9")) | ("23" DIGIT )) 79 IP6-multicast = hexpart [ ":" IP4-multicast ] 80 "/" ttl [ "/" integer ] 81 ; IPv6 address starting with FF00 83 addr = FQDN | unicast-address 85 FQDN = 4*(alpha-numeric|"-"|".") 86 ; fully qualified domain name as specified in 87 ; RFC1035 89 unicast-address = IP4-address | IP6-address 91 IP4-address = b1 "." decimal-uchar "." decimal-uchar "." b4 92 | "0.0.0.0" 94 b1 = decimal-uchar 95 ; less than "224"; not "0" or "127" 97 b4 = decimal-uchar 98 ; not "0" 100 IP6-address = *( HEXDIGIT | "." | ":" ) 101 ; As defined in the IPv6 addressing architecture 103 4. Additional IPv6 Issues in SDP 105 4.1 IPv6 Addresses with Embedded IPv4 Addresses 107 RFC2373 defines two ways in which an IPv4 address may be 108 encoded in an IPv6 address. In both forms, the lower 32 bits 109 of the IPv6 address contain the IPv4 address. The first form is an 110 "IPv4 compatible IPv6 address" and it has the format: 112 | 80 bits | 16 | 32 bits | 113 +--------------------------------------+--------------------------+ 114 |0000..............................0000|0000| IPv4 address | 115 +--------------------------------------+----+---------------------+ 117 The second form of address is used to represent the addresses of 118 IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses. 119 This type of address is termed an "IPv4-mapped IPv6 address" and has 120 the format: 122 | 80 bits | 16 | 32 bits | 123 +--------------------------------------+--------------------------+ 124 |0000..............................0000|FFFF| IPv4 address | 125 +--------------------------------------+----+---------------------+ 127 The difference in format is significant and MAY be treated 128 differently in SDP implementations. 130 5. Example SDP description with IPv6 addresses 132 The following is an example SDP description using the above ABNF 133 for IPv6 addresses. In particular, the origin, URI, and connection 134 fields contain IPv6 addresses. The URI contains an IPv4 compatible 135 IPv6 address. 137 v=0 138 o=nasa1 971731711378798081 0 IN IP6 2201:056D::112E:144A:1E24 139 s=(Almost) live video feed from Mars-II sattelite 140 u=http://[::FFFF:10.2.12.126]/marsII 141 p=+1 713 555 1234 142 c=IN IP6 FF00:03AD::7F2E:172A:1E24 143 t=3338481189 3370017201 144 m=audio 6000 RTP/AVP 2 145 a=rtpmap:2 G726-32/8000 146 m=video 6024 RTP/AVP 107 147 a=rtpmap:107 H263-1998/90000 149 6. Backward compatibility 151 An implementation that does not understand or wish to accept 152 the IPv6 extensions to the SDP grammar MUST reject the SDP. 154 7. IANA Considerations 156 This document updates the definition of the IP6 addrtype parameter 157 found in RFC2327. 159 8. Security Considerations 161 No additional considerations above what is stated in section 7 of 162 RFC2327. 164 9. References 166 [1] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", 167 RFC2373, IETF. 169 [2] M. Handley and V. Jacobson, "Session Description Protocol", 170 RFC2327, IETF. 172 [3] R. Hinden, et. al., "Format for Literal IPv6 Addresses in URL's", 173 RFC2732, IETF. 175 [4] D. Crocker and P. Overell, 176 "Augmented BNF for Syntax Specifications: ABNF", 177 RFC2234, IETF. 179 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 180 Levels", RFC2119, IETF. 182 10. Author's Addresses 184 Sean Olson 185 Richardson, Texas 186 USA 188 Email: seancolson AT yahoo.com 190 Gonzalo Camarillo 191 Ericsson 192 Advanced Signalling Research Lab. 193 FIN-02420 Jorvas 194 Finland 196 Phone: +358 9 299 3371 197 Fax: +358 9 299 3118 198 Email: Gonzalo.Camarillo@ericsson.com 200 Adam Roach 201 Ericsson 202 Richardson, Texas 203 USA 205 Phone: +1 972 583 7594 206 Fax: +1 972 669 0154 207 Email: Adam.Roach@ericsson.com