Subject: RE: [MMUSIC] IPv4 and IPv6 interworking

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Oct 2003 11:58:52 -0700

Thanks, I'll take a look at using that to our advantage with
IPv4/v6 interworking.

-d

> -----Original Message-----
> From: NAKAMURA, Hidefumi [mailto:[email-masked]]
> Sent: Monday, September 29, 2003 9:44 PM
> To: Dan Wing
> Cc: James M. Polk; IETF MMUSIC
> Subject: Re: [MMUSIC] IPv4 and IPv6 interworking
> 
> 
> Hi.
> 
> If you establish a session with SIP, I think RFC3312 mechanism may help
> to solve this problem though some extension will be needed.
> (and also in case that the SIP messages are exchanged in IPv4 packets)
> 
> RFC3312 describes how to negotiate SDPs between two endpoints without
> sending independent INVITE messages twice though it is for the QoS
> negotiation.
> 
> > > At 01:14 PM 9/29/2003 -0700, Dan Wing wrote:
> > > >Let's say a Alice capable of sourcing/sinking both IPv4 and 
> > > >IPv6, and Alice
> > > >wants to establish a session with Bob.  Alice doesn't know, a 
> > > >priori, if Bob
> > > >supports IPv4 or IPv6.  Let's also say that Bob only supports IPv4.
> > > 
> > > What's the normal response of an IPv4 device that receives an 
> > > IPv6 packet? 
> > > This seems like a good place to start...
> > 
> > Yes, but it didn't receive an IPv6 packet -- it receives a SIP 
> > packet from its IPv4-only SIP proxy, but the SDP describes an 
> > IPv6 session.
> > 
> > The normal reaction to an SDP session you can't support is well
> > understood.  I'm asking if that's all folks expect out of IPv4/
> > IPv6 interworking.
> > 
> > -d
> > 
> > > >Does Alice have to send an Offer with IPv6, have Bob reject the 
> > > Offer, and
> > > >then Alice has to send another Offer for IPv4?
> > > >
> > > >RFC3266 describes SDP for IPv6, but it appears it isn't possible to
> > > >simultaneously offer both IPv4 and IPv6 in SDP.
> > > >
> > > >-d
> > > >
> > > >
> > > >_______________________________________________
> > > >mmusic mailing list
> > > >[email-masked]
> > > >https://www1.ietf.org/mailman/listinfo/mmusic
> > > 
> > > 
> > > cheers,
> > > James
> > > 
> > >                                 *******************
> > >                  Truth is not to be argued... it is to be presented
> > > 
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> 
> -- 
> NAKAMURA, Hidefumi 
> NTT ServiceIntegration /NetworkServiceSystems Labs.
> tel: +81(422)59 3904; fax:+81(422)60 4012
> ---
> 

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 1 Oct 2003 12:02:33 -0700

Thanks, Jonathan.

-d

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Monday, September 29, 2003 11:55 PM
> To: Dan Wing
> Cc: IETF MMUSIC
> The right way to do this is with the alt mechanism:
> http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-alt-01.txt
> 
> in concert with ICE:
> http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt
> 
> THe alt mechanism allows Alice to tell Bob about both the v4 and v6 
> addresses, and the ICE mechanism (which will be revised as an mmusic 
> work item per the last ietf meeting) allows for connectivity in more 
> complex cases than the one you describe below. In particular, when 
> Alice is v6 only and there is a 6to4 nat.
> 
> -Jonathan R.
> 
> Dan Wing wrote:
> 
> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
> Chief Technology Officer                    Parsippany, NJ 07054-2711
> dynamicsoft
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>