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 protected]" <[email protected]> > To: Ray Hunter <[email protected]> > Cc: "[email protected]" <[email protected]>; BINET David OLNC/OLN > <[email protected]> > Sent: Friday, 12 October 2012 8:00 PM > Subject: RE: draft-boucadair-6man-sip-proxy-01 > > Dear Ray, > > Thank you for the comments. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Ray Hunter [mailto:[email protected]] >> Envoyé : vendredi 5 octobre 2012 21:45 >> À : BOUCADAIR Mohamed OLNC/OLN >> Cc : [email protected] >> Objet : Re: draft-boucadair-6man-sip-proxy-01 >> >> 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. > > 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. > > >> >> 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). > > 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. > >> >> 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. > > 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. > >> >> regards, >> RayH >> >> [email protected] wrote: >>> Dear all, >>> >>> Comments are more than welcome. >>> >>> Cheers, >>> Med >>> >>> -----Message d'origine----- >>> De : [email protected] >> [mailto:[email protected]] De la part de >> [email protected] >>> Envoyé : jeudi 4 octobre 2012 09:12 >>> À : [email protected] >>> 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=aft-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 protected] >>> 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 >>> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [email protected] > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
