Subject: Re: [MMUSIC] Liaison from 3GPP on how to encode theinvalidconnection address in IPv4,

From: "Philip Hodges" <[email-masked]>
Date: Tue, 5 Aug 2008 23:32:47 +1000

Hi,
can you explain to me the process from now on with this LS - will a
draft be circulated on this exploder for further comment before being
returned to CT4 ?

best regards,

Phil Hodges
Ericsson
Mobile: +61404069546

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Philip Hodges
Sent: Tuesday, 29 July 2008 9:18 AM
To: [email-masked]
Subject: Re: [MMUSIC] Liaison from 3GPP on how to encode
theinvalidconnection address in IPv4, 

Hi Jonathan,
 
I just wanted to clarify that the intended use is strictly within the
bounds of 3GPP SIP-I Core Network. The profile rules will not permit
signalling of unspecified connection address (in any form) outside of
the PLMN so in my understanding provided that IETF would endorse use of
.invalid for "new implementations where no interworking/interoperability
issues would occur" then I dont see a problem with this. I believe the
concern within 3GPP would be that IETF would not permit the use of
.invalid for IPv4 but this does not appear to be the case as described
by Brett below ? So the main concern is receipt of .invalid by existing
IPv4 implementations but 3GPP SIP-I does not have any existing
implementations - it will be first available in Release 8 which is not
yet approved.
Best Regards,
Phil
 
Jonathan Rosenberg wrote:
 
I think its dangerous to assume .invalid will work with IPv4 hosts. Most
will not know that it means something special, attempt to look it up,
fail the DNS query, and probably do something like terminate the call.
We were able to make this work for v6 because there was no backwards
compatibility issue. 
So my response would be that they should not use .invalid for v4.

-Jonathan R.

Brett Tate wrote:

		The liaison statement referenced below by Gonzalo
indicates that the IPv4 0.0.0.0 is currently used as a means to signal
an invalid connection address in IPv4. The liaison statement asks |
"whether the .INVALID address may be used to | indicate an unspecified
IPv4 connection | address and does IETF offer any | recommendation in
this respect ?". 
		--- specification wise
		
		We had a thread on mmusic related to something close to
this back in 2004: 
	
http://www.ietf.org/mail-archive/web/mmusic/current/msg02532.html
		
		due to the requirement of rfc 3264 Offer/Answer to
require an agent to accept 0.0.0.0 (" An agent MUST be capable of
receiving SDP with a connection address of 0.0.0.0, in which case it
means that neither RTP nor RTCP should be sent to the peer."). The
thread seemed to conclude that 0.0.0.0 should be used for IPv4 and
.invalid for IPv6 but the question of .invalid for IPv4 was not debated
directly. 
				After a quick check, the SDP BNF
notations from RFC 4566 and its predecessors RFC 2326 & 3266 seem to
allow the use of .invalid for IP4 connections (a connection address may
be represented as an FQDN and .invalid is a valid TLD). 

	AFAIK, no rfc has defined TLD ".invalid" to have the same
meaning as
	"0.0.0.0" within rfc3264.  RFC 3725 does indicate to look for
future
	specification.  However AFAIK, only
draft-ietf-sipping-v6-transition has
	updated rfc3264 with such usage but only discusses IP6.

		--- implementation wise
		
		0.0.0.0 is typically handled by implementers given the
2543 history and the 3264 MUST requirement. How would today's
implementations react to "c=IN IP4 .invalid"? can folks provide some
feedback? 

	Although it appears valid per rfc4566 ABNF, isn't something
needed prior
	to ".invalid" to be structured like a valid FQDN?
	
	Until more devices support IPv6, I assume many will not treat
IP4 TLD
	".invalid" like "0.0.0.0".  However once IPv6 supported, I
assume some
	will interpret receiving IP4 TLD ".invalid" similar to
"0.0.0.0";
	however they likely would not send it unless interoperability
concerns
	have been alleviated.

 

 

Phil Hodges

Core Network Standardisation

Mobile: +61404069546

Fax:       +61395308658

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

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 5 Aug 2008 07:50:45 -0600

We discussed this response last Friday 4/8 during the mmusic meeting at
IETF#72 (see mmusic slides from chairs for a response proposal).

A few comments were made at the mike during the session:
 - Gonzalo stressed the fact that this LS was related to SDP use in
H.248 and hence that we should indicate in the LS reply that most of the
feedback we got was from the SIP community;
 - I stated that while the question seems related to H.248 SDP use, MGCs
tend to have SIP legs and re-use SDP exchanged across the H.248 and SIP
exchanges 
 - Tom Taylor added that indeed, H.248 SDP interop with what SIP UA do
is important
Therefore, the consensus is still to respond that 0.0.0.0 is
recommended.  

I will circulate a draft LS reply before the end of this week
summarizing what I think is the wg consensus on this question.

Finally, Keith Drage and I had a brief chat after the MMUSIC session
related to this.  Keith correctly pointed out that the requirement we
have pointed at to justify the support for 0.0.0.0 to indicate an
invalid IPv4 connection address is in RFC 3264 O/A which is applicable
to SIP mostly.  We should write up something more generic about this,
may be in a short draft, may be in 4566bis.  Thoughts?

Jean-Francois.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Philip Hodges
> Sent: Tuesday, August 05, 2008 7:33 AM
> To: [email-masked]
> Subject: Re: [MMUSIC] Liaison from 3GPP on how to
> encodetheinvalidconnection address in IPv4,
> 
> Hi,

---

From: "Philip Hodges" <[email-masked]>
Date: Wed, 6 Aug 2008 00:15:23 +1000

Hi Jean-Francois,
thankyou for the update. I understand that for the open SIP community
the current assumption for IPv4 is for 0.0.0.0 but firstly RFC7325
states "Note that the usage of 0.0.0.0, though recommended by RFC 3264,
has numerous drawbacks. It is anticipated that a future specification
will recommend usage of a domain within the .invalid DNS top level
domain instead of the 0.0.0.0 IP address." and secondly as pointed out
below if it is clear that the application will not be signalling the
unspecified connection address outside of the 3GPP domain then backwards
compatiblity should not be an issue for 3GPP. It is therefore desirable
to have a single solution within 3GPP that is independent of IP version.
So if this point is agreed then I would assume that the LS would
indicate the preferred handling would be for 0.0.0.0 where backward
compatiblity would be an issue but if no signalling to external SIP UAs
will occur then use of .invalid would not be a problem ?

cheers,

Phil Hodges
Ericsson
Mobile: +61404069546

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Tuesday, 5 August 2008 11:51 PM
To: Philip Hodges; [email-masked]
Subject: RE: [MMUSIC] Liaison from 3GPP on how to

is important Therefore, the consensus is still to respond that 0.0.0.0
is recommended.  

Jean-Francois.

> the PLMN so in my understanding provided that IETF would endorse use 
> of .invalid for "new implementations where no 
> interworking/interoperability issues would occur" then I dont see a 
> problem with this. I believe the concern within 3GPP would be that 
> IETF would not permit the use of .invalid for IPv4 but this does not 
> appear to be the case as described by Brett below ? So the main 
> concern is receipt of .invalid by existing

> 		The liaison statement referenced below by Gonzalo
indicates that the 
> IPv4 0.0.0.0 is currently used as a means to signal an invalid 
> connection address in IPv4. The liaison statement asks | "whether the 
> .INVALID address may be used to | indicate an unspecified
this back in 
> 2004:
require an agent 
> to accept 0.0.0.0 (" An agent MUST be capable of receiving SDP with a 
> connection address of 0.0.0.0, in which case it means that neither RTP

> nor RTCP should be sent to the peer."). The thread seemed to conclude 
> that 0.0.0.0 should be used for IPv4 and .invalid for IPv6 but the 
> question of .invalid for IPv4 was not debated directly.
> allow the use of .invalid for IP4 connections (a connection address 
> may be represented as an FQDN and .invalid is a valid TLD).
> 
meaning as
future
> 	Although it appears valid per rfc4566 ABNF, isn't something
needed 
> prior
assume 
> some
"0.0.0.0";

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2008 10:30:49 -0400

Philip Hodges wrote:
> domain instead of the 0.0.0.0 IP address."

This was discussed some time ago, without coming to any final 
conclusion. However, IMO making such a change is all pain and no gain. 
The 0.0.0.0 mechanism works, and is used. Any change will have to be 
backward compatible, which means implementations must continue to 
support it. So what is the gain from switching? Anybody who sends a 
*.invalid domain instead of 0.0.0.0 will have to deal with the 
possibility that it won't be understood, and will know that if it uses 
0.0.0.0 it won't have that risk.

I think this has as much chance of being adopted as SDPng.

	Thanks,
	Paul

> and secondly as pointed out

---

From: Christian Groves <[email-masked]>
Date: Wed, 06 Aug 2008 11:05:20 +1000

Hello,

 From reading the LS I don't see that the H.248 SDP is relevant to the 
issue. The Nc interface is between MSC Servers, not between a MSC and MG 
(i.e. Mc interface) which would be covered by H.248. From the issue 
described in the LS it appears that it is the MSC that decides to defer 
the selection, not the MG (i.e. the MG would not need to provide an 
unspecified address via H.248 SDP).

Can anyone from 3GPP confirm if this is the case or not?

Regards, Christian

Jean-Francois Mule wrote:
>> Behalf
>> may

---

From: "Philip Hodges" <[email-masked]>
Date: Wed, 6 Aug 2008 12:16:53 +1000

Hi Christian,
this is correct, the MSC will indicate "unspecified connection address"
because it has not seized a MGW. 

It is clear from the discussion that for existing IPv4 SIP UAs proposing
.invalid would only be an addition not a replacement (as Paul Kyzivat
clearly indicated his position) but as I have stated (but noone has
commented on this aspect) for 3GPP CS Core Network there is no existing
SIP implementation and the 3GPP specifications will require that the use
of "unspecified connection address" shall not be signalled outside of
the PLMN (MGWs cannot be shared beyond the operator controlled domain).
BR,

Phil Hodges
Ericsson
Mobile: +61404069546

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christian Groves
Sent: Wednesday, 6 August 2008 11:05 AM
To: [email-masked]
Subject: Re: [MMUSIC] Liaison from 3GPP on how to
encodetheinvalidconnection address in IPv4, 

Hello,

Regards, Christian

Jean-Francois Mule wrote:
> H.248 and hence that we should indicate in the LS reply that most of 
> the feedback we got was from the SIP community;
>  - I stated that while the question seems related to H.248 SDP use, 
> MGCs tend to have SIP legs and re-use SDP exchanged across the H.248 
> and SIP exchanges

>> implementations - it will be first available in Release 8 which is 
>> not yet approved.
>> Best Regards,
>> Phil
>>

>> 		The liaison statement referenced below by Gonzalo
indicates that 
>> the IPv4 0.0.0.0 is currently used as a means to signal an invalid 

>> 		We had a thread on mmusic related to something close to
this back 
>> in 2004:
require an agent 

>> connection address of 0.0.0.0, in which case it means that neither 
>> RTP nor RTCP should be sent to the peer."). The thread seemed to 
>> conclude that 0.0.0.0 should be used for IPv4 and .invalid for IPv6 
>> but the question of .invalid for IPv4 was not debated directly.
meaning as
future
needed 
assume 
"0.0.0.0";

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Aug 2008 22:40:31 -0400

Philip,

On a closed network you can of course do as you wish.
But then please don't call it SIP, because it won't be.

	Paul

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 6 Aug 2008 13:23:39 +0200

Hi Christian, Paul, Phil,

as one of the people who were involved in the discussion that triggered
this LS, I can confirm that the questions refer to SDP in SIP signalling
(although we also have a split architecture and therefore will also need
to define the H.248 encoding, which will apply the smae rules with some
likelihood).

Although the 3GPP CS domain is a closed network, the motivation for
using SIP there was to follow industry trends. Therfore in my view there
is an intrest within 3GPP to avoid unnecessry deviations from standard
SIP. Further, at the edge we will interwork with external SIP usage and
there is also some benefit if we can avoid diffrent procedures between
the interworking node and 3GPP-internal nodes.
In my view this was part of the reason why we wrote the LS in 3GPP
instead of taking a decision independentley.

Therefore the view of the IETF how the invalid connection address is
encoded in a standard SIP network is the appropriate answer for 3GPP. It
is then up to 3GPP to discuss how important this information is for
their encoding decision within the 3GPP CS domain.

Thomas

---------------------------------- 
Dr. Thomas Belling 
Nokia Siemens Networks  GmbH & Co. KG.         

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Paul Kyzivat
> Sent: Wednesday, August 06, 2008 4:41 AM
> To: Philip Hodges
> Cc: [email-masked]
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Christian Groves
> >> We discussed this response last Friday 4/8 during the 
> mmusic meeting 
> >> at
> >>> I think its dangerous to assume .invalid will work with 
> IPv4 hosts.
> >>> Most