Subject: RE: [Speermint] Reachability

From: "Reinaldo Penno" <[email-masked]>
Date: Tue, 4 Apr 2006 16:40:06 -0400

Hello Patrick,

Suddenly I'm some 30 emails behind but...

That's what I was trying to say _if_ by publicly addressable you mean a
mapping somewhere in the case of RFC1918 addresses. As some people
mentioned (Sohel, Richard), including you, the main points are:

1) SIP entities (just like emails, web servers and others) can be on a
private network, that's perfect fine, but a mapping somewhere is needed
to communicate with non-RFC1918 endpoints.

2) Between the mapping ingress point and the actual SIP entity, you can
traverse many layer 3 hops, VPNs, etc. that's perfect fine. All this
infrastructure is out there and working. The only requirement for
communication with non-RFC1918 IP addresses is (1) above.

3) There is no mapping needed anywhere if all entities are in a private
address space and only communicate with each other - this is the
traditional Layer 3 VPN. 

As I mentioned the rules of host to host and email communication should
apply to SIP otherwise we will need to invent another internet for it. 

Regards,

Reinaldo

> -----Original Message-----
> From: Patrick Melampy [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 6:29 AM
> To: Reinaldo Penno; 'Hadriel Kaplan'; [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> Reinaldo -- I agree with your assertions.
> 
> But I want to ensure everybody understands what your really saying
here.
> 
>   Before somebody mentions it...for a UA behind a NAT to be reachable,
>   he/she needs a public NAT binding so that a session _initiated_ from
the
>   public side can be made to him/her.
> 
> This means that for carrier to carrier peering models, each and every
> customer of every carrier that wants to inter-connect needs to have a
> 'public NAT binding'.
> 
> I believe by extension, this means that a serving proxy/registrar for
the
> target of a communication must ALSO have either a public address or a
> public
> NAT binding.
> 
> The conclusion here -- every endpoint and every serving
proxy/registrar
> needs to be publicly addressable.
> 
> Am I correct?
> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 5:29 AM
> To: Hadriel Kaplan; [email-masked]
> Subject: RE: [Speermint] Reachability
> 
> Hello Hadriel,
> 
> Comment inline....
> 
> > -----Original Message-----
> > From: Hadriel Kaplan [mailto:[email-masked]]
> > Sent: Monday, April 03, 2006 11:01 PM
> > To: Reinaldo Penno; [email-masked]
> > Subject: RE: [Speermint] Reachability
> >
> > Hi Reinaldo,
> > Comments inline...
> >
> > > -----Original Message-----
> > > From: Reinaldo Penno [mailto:[email-masked]]
> > >
> > > Maybe I'm missing something, but given that this workgroup is
> interested
> > > only in call routing (E.164 is out of scope), do we really need to
> care
> > > about that? An AoR in the end will be translated to an IP address,
> and
> > > IP addresses have a very good definition of public and private (in
> IPv4
> > > and IPv6).
> >
> > I don't understand fully what you mean.  An AoR is only fully
> "translated"
> > to an IP Address (and really to a contact URI) by the AoR's domain.
> So
> > what
> > you're saying is if the AoR's user-part represents a consumer behind
a
> > home
> > NAT (a private IP), then it is a private AoR; but for those
consumers
> who
> > don't use home-NATs then it's a public AoR?
> [[Reinaldo]]
> 
> Hello,
> 
> Actually I'm trying to understand the whole purpose of the discussion,
> that's why I gave that example. I was trying to understand why it
> matters, before getting knee deep into the classification. Can someone
> refresh that for me?
> 
> So, if SIP peering is going to get woven into the fabric of the
> internet, the rules for domains names, DNS resolution, private vs.
> public IP address, etc should apply, right?
> 
> I believe the current model of host to host or email communication is
> not different for SIP. We could have the following main
> situations...(correct me where I'm wrong).
> 
> 1) The AoR (just like a traditional domain name or email), in the end
> will get resolved into an IP address. Then there are only two
> situations.
> 
>    a) the IP address is private (RFC 1918).
> 
>    This means the SIP endpoint is unreachable unless you are also in
the
> same private network. Actually I believe a private IP address cannot
> even be provisioned in a public DNS.
> 
>    Before somebody mentions it...for a UA behind a NAT to be
reachable,
> he/she needs a public NAT binding so that a session _initiated_ from
the
> public side can be made to him/her.
> 
>    b) the IP address is public.
> 
>    The SIP endpoint is theoretically reachable.
> 
> 2) The AoR cannot get translated. Again, just like the Internet we
have
> today, this means the domain name/user is private, does not exist, etc
> 
> All this has been happening okay with just a few basic rules. If an
AoR
> is very similar to an email address, why it would not work with the
> current infrastructure/definitions?
> 
> If somebody says that they have a "private" email address or domain
> name, what is your interpretation of that?
> 
> Regards,
> 
> Reinaldo
> 
> 
> 
> 
> 
> 
>  And if the AoR gets
> > translated
> > into an IP by a registrar inside a private IP subnet, and somehow it
> later
> > gets translated into the public IP address space, that's also
private
> > because the AoR was translated to a private IP originally?
> >
> > Or maybe you mean what the domain part of the AoR resolves to?
> >
> > > For you to be "SIP reachable", you need to be IP reachable first,
> let's
> > > not forget about that. And if you are IP reachable, you could
> > > potentially be SIP reachable by registering to some free SIP
service
> (or
> > > the SIP "domain" above you in the hierarchy...if this was the
> email/DNS
> > > model).
> >
> > Actually, to be very specific ultimate target of the AoR can be "sip
> > reachable" but not IP reachable.  But I think for now we should
ignore
> the
> > implications of that, unless it becomes a problem.
> >
> > -hadriel
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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