[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Philip Hodges wrote:

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."
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
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:jf.mule at cablelabs.com] Sent: Tuesday, 5 August 2008 11:51 PM 
To: Philip Hodges; mmusic at ietf.org
Subject: RE: [MMUSIC] Liaison from 3GPP on how to
encodetheinvalidconnection address in IPv4, 
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.


-----Original Message-----
From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of Philip Hodges 
Sent: Tuesday, August 05, 2008 7:33 AM
To: mmusic at ietf.org
Subject: Re: [MMUSIC] Liaison from 3GPP on how to encodetheinvalidconnection address in IPv4, 

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: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On Behalf Of Philip Hodges 
Sent: Tuesday, 29 July 2008 9:18 AM
To: mmusic at ietf.org
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
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic