Subject: [MMUSIC] Blank IPv6 c lines

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jun 2005 07:52:32 +0300

Folks,

when a SIP user agent cannot provide an IPv4 address for some reason 
(e.g., in third-party call control scenarios) it uses the following 'c' 
line:

c=IN IP4 0.0.0.0

Do we have an equivalent for IPv6 'c' lines? If not, we need to come up 
with something.

Thanks,

Gonzalo

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jun 2005 09:34:37 -0400

> Do we have an equivalent for IPv6 'c' lines? If not, we need to come up 

AFAIK we don't have an equivalent.

But why would we need one? Does it really matter if the "null" address 
is IPv4 or IPv6? Either way I am not going to be sending or receiving 
with it.

	Paul

---

From: "Louis Alexander" <[email-masked]>
Date: Tue, 21 Jun 2005 09:46:56 -0400

Is this not an appropriate place to use a SDP attribute such as a=sendonly
or a=inactive?

Louis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Tuesday, June 21, 2005 9:35 AM
To: Gonzalo Camarillo
Cc: mmusic
Subject: Re: [MMUSIC] Blank IPv6 c lines

	Paul

This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an
intended recipient then please promptly delete this e-mail and any
attachment and all copies and inform the sender. Thank you.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jun 2005 17:48:01 +0300

Paul,

I am concerned with IPv6-only user agents. If they see an IP4 address 
they will assume they do not understand it. They will not even parse the 
0.0.0.0 part. We may also think of a solution that is address type 
independent. Something like c=null.

Louis,

an inactive stream still carries RTCP traffic... a null c line is 
something different.

Thanks,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 21 Jun 2005 16:12:23 +0100

Gonzalo,

I have a vague recollection of an IESG review comment that suggested using 
the .invalid domain in this context, even for IPv4 (because 0.0.0.0 wasn't a 
real address).  I'm not sure what the details were though, or where to find 
out more.  Maybe it was with regard to third party control, or offer answer. 
In that case it was decided that such an option wouldn't be backward 
compatible with what was deployed, but it maybe appropriate for IPv6.

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware
http://www.tech-know-ware.com/lmx
for LMX XML to C++ binding
(or http://www.xml2cpp.com)
=============================================

----- Original Message ----- 
From: "Gonzalo Camarillo" <[email-masked]>
To: "Louis Alexander" <[email-masked]>
Cc: "'Paul Kyzivat'" <[email-masked]>; "'mmusic'" <[email-masked]>
Sent: Tuesday, June 21, 2005 3:48 PM
Subject: Re: [MMUSIC] Blank IPv6 c lines

> Paul,
>
> I am concerned with IPv6-only user agents. If they see an IP4 address they 
> will assume they do not understand it. They will not even parse the 
>> But why would we need one? Does it really matter if the "null" address is 
>> IPv4 or IPv6? Either way I am not going to be sending or receiving with 
>> it.
>>
>> Paul
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jun 2005 13:19:19 -0400

> independent. Something like c=null.

Anything one does here introduces backward compatibility issues for 
those that already support the c=IN IP4 0.0.0.0 but nothing else. And 
even if you were to invent something else, the IPv6 UAs will need to be 
changed to support it. Why not just change them to support this 
particular special case of an IPv4 address? Just consider it a peculiar 
notation for c=null.

	Paul

>>> (e.g., in third-party call control scenarios) it uses the following 
>>> 'c' line:
>>>
>>> c=IN IP4 0.0.0.0
>>>
>>> Do we have an equivalent for IPv6 'c' lines? If not, we need to come 
>>> up with something.
>>
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jun 2005 13:27:30 -0400

Pete Cordell wrote:
> Gonzalo,
> 
> I have a vague recollection of an IESG review comment that suggested 
> using the .invalid domain in this context, even for IPv4 (because 
> 0.0.0.0 wasn't a real address).  I'm not sure what the details were 
> though, or where to find out more.  Maybe it was with regard to third 
> party control, or offer answer. In that case it was decided that such an 
> option wouldn't be backward compatible with what was deployed, but it 
> maybe appropriate for IPv6.

Yes, there was such a proposal. And yes, I pointed out that it wasn't 
backwards compatible. So I *think* the whole idea was dropped.

Because of the need to preserve backward compatibility, UAs will need to 
support c=IN IP4 0.0.0.0. I see little value in introducing another 
notation, which will simply further complicate implementations.

About the only thing that might be achieved by coming up with some other 
notation for this is to improve the "elegance" of the representation. 
But "elegance" and "sdp" don't belong in the same sentence, so I 
wouldn't spend much time on that.

As inelegant as it is, I think it would be simpler and less disruptive 
to simply declare c=IN IP4 0.0.0.0 as *the* way to specify "no address", 
that should be understood regardless of what transport protocol is 
otherwise used.

	Paul

> ----- Original Message ----- From: "Gonzalo Camarillo" 
> <[email-masked]>
>> they will assume they do not understand it. They will not even parse 
>> the 0.0.0.0 part. We may also think of a solution that is address type 
>>> But why would we need one? Does it really matter if the "null" 
>>> address is IPv4 or IPv6? Either way I am not going to be sending or 
>>> receiving with it.
>>>
>>> Paul
>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jun 2005 21:25:20 +0300

Paul,

I agree with you on all those points. However, I am thinking of the case 
when a user agent needs to provide an IPv6 and an IPv4 address using 
ANAT (e.g., the user agent is a 3pcc controller). How does the answerer 
knows that what is being offered is an IPv6 line and an IPv4 line? The 
answerer will only see two m lines with c=IN IP4 0.0.0.0

Thanks,

Gonzalo

Paul Kyzivat wrote:
>> party control, or offer answer. In that case it was decided that such 
>> an option wouldn't be backward compatible with what was deployed, but 
>> it maybe appropriate for IPv6.
> 
> 
>>> the 0.0.0.0 part. We may also think of a solution that is address 
>>> type independent. Something like c=null.
>>>
>>> Louis,
>>>
>>>>> when a SIP user agent cannot provide an IPv4 address for some 
>>>>> reason (e.g., in third-party call control scenarios) it uses the 
>>>>> following 'c' line:
>>>>>
>>>>> c=IN IP4 0.0.0.0
>>>>>
>>>>> Do we have an equivalent for IPv6 'c' lines? If not, we need to 
>>>>> come up with something.
>>>>
>>>>
>>>>
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jun 2005 15:38:31 -0400

> answerer will only see two m lines with c=IN IP4 0.0.0.0

The answerer isn't being offered either an IPv4 or an IPv6 address - it 
is being offered a null address. In the case when the null address is 
being offered, what purpose would be served by offering both a v4 and a 
v6 form?

If a null address is being offered, then before real communication can 
occur a new address will have to be negotiated. At that time a choice of 
v4 and v6 can be made.

	Paul

>> Because of the need to preserve backward compatibility, UAs will need 
>> to support c=IN IP4 0.0.0.0. I see little value in introducing another 
>> About the only thing that might be achieved by coming up with some 
>> other notation for this is to improve the "elegance" of the 
>> representation. But "elegance" and "sdp" don't belong in the same 
>> sentence, so I wouldn't spend much time on that.
>>
>> to simply declare c=IN IP4 0.0.0.0 as *the* way to specify "no 
>> address", that should be understood regardless of what transport 
>> protocol is otherwise used.
>>
>>     Paul
>>
>>> Pete.
>>> -- 
>>>> I am concerned with IPv6-only user agents. If they see an IP4 
>>>> address they will assume they do not understand it. They will not 
>>>> even parse the 0.0.0.0 part. We may also think of a solution that is 
>>>> address type independent. Something like c=null.
>>>>
>>>> Louis,
>>>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jun 2005 22:50:09 +0300

Paul,

the offerer is offering a null address, but the answerer needs to know 
which address type to provide in the answer. If the offer contains a 
null IPv4 and a null IPV6 address, the answerer knows that it can use 
any of them. If the offer just contains a generic null address, the 
answerer does not know which address type to use in the answer.

That is, even if the offerer cannot provide a particular address at this 
point, it can at least negotiate the address type to be used.

Gonzalo

Paul Kyzivat wrote:
> 
> 
> Gonzalo Camarillo wrote:
> 
>> Paul,
>>
>> I agree with you on all those points. However, I am thinking of the 
>> case when a user agent needs to provide an IPv6 and an IPv4 address 
>> using ANAT (e.g., the user agent is a 3pcc controller). How does the 
>> answerer knows that what is being offered is an IPv6 line and an IPv4 
>> line? The answerer will only see two m lines with c=IN IP4 0.0.0.0
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jun 2005 17:03:10 -0400

> point, it can at least negotiate the address type to be used.

Hmm. I just looked at 3264, and I find no disucssion of negotiation of 
network type. As far as 3264 is concerned it appears fine to offer an 
IPv4 address and get an answer with an IPv6 address. Of course in 
practice this may not be fine. (Or is this specified someplace I missed.)

I think you are assuming that there is an additional rule in 
offer/answer - that answered network type should be the same as offered 
network type. If so, then there is indeed a problem if somebody wants to 
offer a null address but desires an IPv6 answer. If so, then I guess it 
may be necessary to devise an IPv6 equivalent of c=IN IP4 0.0.0.0. If 
so, then I think an ammendment to 3264 is also required.

	Paul

>> The answerer isn't being offered either an IPv4 or an IPv6 address - 
>> it is being offered a null address. In the case when the null address 
>> is being offered, what purpose would be served by offering both a v4 
>> and a v6 form?
>>
>> occur a new address will have to be negotiated. At that time a choice 
>> of v4 and v6 can be made.
>>
>>     Paul
>>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Jun 2005 00:51:20 -0400

inline.

Paul Kyzivat wrote:

>> That is, even if the offerer cannot provide a particular address at 
>> this point, it can at least negotiate the address type to be used.
> 
> 

I agree with Paul, this is not specified in RFC3264.

> network type.

I think it should. Things will get really complicated and ugly 
otherwise. If I offer up a v4 address, how would the answerer know that 
it is OK to provide a v6 answer? It could only do so if the sender had 
the ability to send packets to a v6 address, which may not be possible. 
Also, over time, it has become clear that symmetric operation is highly 
preferable, and this is built-in to the ICE algorithms. Using different 
networks for send and receive obviously won't work with that.

> If so, then there is indeed a problem if somebody wants to 

I also agree here.

I'd suggest that, for v6, we allow for a .invalid domain name, but only 
for v6 endpoints. v4 would continue with 0.0.0.0. Since there are no v6 
endpoints doing this yet, this presents no backwards compatibility 
issue, as it did previously for v4.

Sounds like a small draft outlining changes to offer/answer for v6 is 
needed.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com