Subject: draft-boucadair-6man-sip-proxy-01

From: <[email-masked]>
Date: Thu, 4 Oct 2012 09:16:42 +0200

Dear all,

Comments are more than welcome.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 4 octobre 2012 09:12
À : [email-masked]
Objet : I-D Action: draft-boucadair-6man-sip-proxy-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : IPv6 RA Option for SIP Proxy Server
	Author(s)       : Mohamed Boucadair
                          David Binet
	Filename        : draft-boucadair-6man-sip-proxy-01.txt
	Pages           : 6
	Date            : 2012-10-04

Abstract:
   This document specifies a new optional extension to IPv6 Router
   Advertisement messages to advertise SIP Proxy Server (e.g., P-CSCF)
   addresses to IPv6 hosts.

   The provisioning of the SIP Proxy Server address is crucial for the
   delivery of SIP-based services.  Means to ensure reliable delivery of
   this information to connecting SIP User Agents is a must.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-6man-sip-proxy

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-6man-sip-proxy-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-boucadair-6man-sip-proxy-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Ray Hunter <[email-masked]>
Date: Fri, 05 Oct 2012 21:44:37 +0200

I have read this draft and do not support it as-is.

I do not agree with the conclusion that extending RA with a new option 
for SIP is necessary nor desirable.

IMVHO:

1. There are other mechanisms available. DHCPv6 is not mandatory in the 
IPv6 node requirements, but neither is SIP. Adding a new RA option would 
mean firmware in mobile devices would have to be updated, just as they 
would if incorporating a DHCPv6 client, so that's a wash.

2. An FQDN has an indeterminate length, although encoding of an FQDN in 
RFC1035 limits this to 255 octets, it's still potentially a significant 
increase in the length of RA messages, which is undesirable for many 
reasons (including stateless security filtering mechanisms like RA-Guard).

3.There's no padding specified on the FQDN encoding. AFAIK RFC1035 does 
not specify how to encode an FQDN into 8 octet blocks (required for RA 
options length calculations).

4. You can hardly talk about advantages of using an RA option rather 
than an alternative unicast mechanism on a point to point bearer link 
(where no other nodes can listen out for the broadcast/multicast 
information to save on multiple transmissions). The end node still also 
has to resolve the FQDN into one or more IPv6 or IPv4 addresses via DNS 
before it can transmit any SIP messages, so it's not exactly a RTT start 
up latency or packet saver either.

Or am I missing something?

regards,
RayH

[email-masked] wrote:
> http://www.ietf.org/rfcdiff?url2=aft-boucadair-6man-sip-proxy-01
>
>

---

From: <[email-masked]>
Date: Fri, 12 Oct 2012 11:00:53 +0200

Dear Ray, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

>De : Ray Hunter [mailto:[email-masked]] 
>Envoyé : vendredi 5 octobre 2012 21:45
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : Re: draft-boucadair-6man-sip-proxy-01
>

Med: I have several comments here:

* The discovery of the SIP Proxy server is almost critical as the discovery of a DNS server (RFC6106): If no server is discovered no session can be placed. This may be critical for no SIM-based terminals (e.g., placing an emergency call).

* With the advent of Mobile VoIP, a solution which ** guarantee ** the provisioning of the SIP Proxy Server is needed. I would argue RA-based method would have less impact on terminals

* This method can be used for auto configuring SIP terminals with a SIP Proxy Server deployed in a homenet context.

* For Fixed-Mobile Convergence, SIP-based traffic may also be interesting to offload (this is similar to local breakout scenarios for the roaming context): having a consistent method to discover the SIP Proxy in both fixed and mobile access would be helpful.

>options length calculations).

Med: You are right, padding may be needed. We can work out better the specification once there is a support to use RA for SIP Proxy Server discovery.

>up latency or packet saver either.

Med: This may or may not be considered as an issue: the reason is there is likely a registration phase before placing a session. Anyway, this issue can be solved by changing the encoding of the name into string. Doing so would:
(1) allow to convey any name (including IP address literals) that can be passed to an underlying resolution library
(2) not require to define two formats (one for fqdn and another one for IP address). One single option will do the job.

>Or am I missing something?

Med: Your questions are valid one. I hope I clarified some of them. Thanks for the review.

>> De : [email-masked] 
>[mailto:[email-masked]] De la part de 
>[email-masked]

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 12 Oct 2012 16:16:24 -0700 (PDT)

Hi,

I agree with Ray, I think this is fundamentally just re-inventing the wheel.

I notice that one of the justifications for this is that "DHCPv6 is not
required in all 3GPP releases." Why isn't it? Based on this statement,
it seems to me that the 3GPP architecture doesn't recognise that there
isn't really anything special about (smart)phones - they're just portable,
single or multi-homed hosts with one or more wireless interfaces, and
therefore should use standard and existing IPv6 mechanisms. Making phone
calls on them is just an application running on the host.

Support for DHCPv6 is a SHOULD for hosts that support more than one
specialised application: http://tools.ietf.org/html/rfc6434#section-7.2.1

I think putting options like this and DNS (and of course, down the
track, most other DHCPv6 options) in RAs is a violation of the Internet
architecture. The Internet is meant to be application transparent,
and I think this is it's greatest strength and advantage compared to the previous
application-specific networks such as the PSTN. It shouldn't be necessary
to upgrade the software/firmware in a router to be able to run a new
application residing on the hosts, yet this is what applications/services
configuration options in RAs would require.

So I think the Internet needs to be kept both services/application
transparent as well as service/application configuration method
transparent. RAs should be left to just configuring the network layer/IP
parameters, and an "over-the-top" protocol, stateless DHCPv6, used to
configure hosts' service and applications. Routers operating as
DCHPv6 relays fit within this model because they're (new) DHCPv6 option
transparent.

Regards,
Mark.

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: Ray Hunter <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>; BINET David OLNC/OLN <[email-masked]>
> Sent: Friday, 12 October 2012 8:00 PM
> Subject: RE: draft-boucadair-6man-sip-proxy-01
> 
> Dear Ray, 
> 
> * The discovery of the SIP Proxy server is almost critical as the discovery of a 
> DNS server (RFC6106): If no server is discovered no session can be placed. This 
> may be critical for no SIM-based terminals (e.g., placing an emergency call).
> 
> * With the advent of Mobile VoIP, a solution which ** guarantee ** the 
> provisioning of the SIP Proxy Server is needed. I would argue RA-based method 
> would have less impact on terminals
> 
> * For Fixed-Mobile Convergence, SIP-based traffic may also be interesting to 
> offload (this is similar to local breakout scenarios for the roaming context): 
> having a consistent method to discover the SIP Proxy in both fixed and mobile 
> access would be helpful.
> 
> 
>> 
> Med: You are right, padding may be needed. We can work out better the 
> specification once there is a support to use RA for SIP Proxy Server discovery.
> 
>> 
> Med: This may or may not be considered as an issue: the reason is there is 
> likely a registration phase before placing a session. Anyway, this issue can be 
> solved by changing the encoding of the name into string. Doing so would:
> (2) not require to define two formats (one for fqdn and another one for IP 
> address). One single option will do the job.
> 
>> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Mon, 15 Oct 2012 08:37:48 +0200

Dear Mark,

Thanks for the comments. 

Please see inline.
Cheers,
Med 

>De : Mark ZZZ Smith [mailto:[email-masked]] 
>Envoyé : samedi 13 octobre 2012 01:16
>À : BOUCADAIR Mohamed OLNC/OLN; Ray Hunter
>Cc : [email-masked]; BINET David OLNC/OLN

Med: Yes, this is only a way to provision a node with another yet channel. No magic there. The question is: are we confident existing tools are sufficient to ensure access to the Internet service in a consistent and homogenous manner whatever the attachment network used by a host? BTW, I'm using the Internet service in a wider definition as defined in RFC1287 (http://tools.ietf.org/rfc/rfc1287.txt): "The Internet should be extended to support "real-time"            applications like voice and video. "

>required in all 3GPP releases." Why isn't it?

Med: Because there is another channel which is supposed to provide such information during PDP Context. This assumption becomes obsolete when you attach to a non 3-GPP network.

 Based on this statement,
>therefore should use standard and existing IPv6 mechanisms.

Med: That's the point. Is there are a guarantee that based on host capabilities and diverse network attachment types, access to the telephony service will be preserved?
 
>Making phone

Med: The only issue is that unlike other Internet applications, provisioning the DNS is not sufficient to work: the information about the proxy server is required. 

>specialised application: 
>http://tools.ietf.org/html/rfc6434#section-7.2.1

Med: SHOULD is not a MUST.  

>architecture.

Med: I disagree:

* There are already examples of protocols violating that model: TCP. (I agree this is not a reason to do it with another protocol.)
* IPv5 (ST) focuses exclusively on real-time services 
* RFC1287 clearly extends the Internet model to real-time services. 

 The Internet is meant to be application transparent,

Med: I would love to; but IP connectivity is heavily dependent of rendezvous services (in all its forms: DNS, SIP registration, etc.)

>application-specific networks such as the PSTN.

Med: See my comment above.

 It shouldn't 
>be necessary

Med: I'm not asking to include all application-related configuration in RA but only the mandatory rendezvous services for Internet service to be correctly be invoked and delivered: 
* DNS is already supported (RFC6106)
* This I-D is claiming SIP-based configuration should also be part of this package.

>> * This method can be used for auto configuring SIP terminals 
>with a SIP Proxy 
>> Server deployed in a homenet context.
>> 
>> (1) allow to convey any name (including IP address literals) 
>that can be passed 
>> to an underlying resolution library
>> Med: Your questions are valid one. I hope I clarified some 
>of them. Thanks for 
>> the review.
>> 
>>> 
>>> regards,
>>> RayH
>>>