Subject: Re: [Speermint] Reachability

From: "Stastny Richard" <[email-masked]>
Date: Tue, 4 Apr 2006 21:39:58 +0200

ENUM is out-of-scope in speermint, it is only providing eventaully inter alia the call routing data
 
speermint is using the call routing data and IMHO it is not defined yet
what is used to locate the next hop.

OTOH, since sip and sip standards are to be used,
RFC3263 implies somewhat the DNS
 
Richard

________________________________

Von: Hadriel Kaplan [mailto:[email-masked]]
Gesendet: Di 04.04.2006 21:21
An: 'Malas, Daryl'; Stastny Richard
Cc: [email-masked]
Betreff: RE: [Speermint] Reachability

Hi Darryl/Richard,
Just a quick question: did the WG decide on ENUM/DNS as the location
mechanism already? (could be, I joined late) 
I like the idea, but it's having the tail wag the dog.  ;)
Seriously, though - we may find a missing piece or 2 if we start with
terminology + requirements.  Sorry if I mis-interpreted your comments.

-hadriel

> -----Original Message-----
> From: Malas, Daryl [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 1:34 PM
> To: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> [email-masked]
> Subject: RE: [Speermint] Reachability
>
> Comments in-line...
>
> Daryl M.
>
> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 11:27 AM
> To: Malas, Daryl; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> [email-masked]
> Subject: Re: [Speermint] Reachability
>
> Nice analysis, and useful
>
> But I think we get more and more down to L2 and L3, but our prime
> or first goal is to enable peering on L5.
> to do so, we basically need a common database to get the routing
> information
>
> [Daryl]  I agree, by defining the environment (e.g. public, private,
> carrier), I think it will be easier to specify the required database.
>
> Of course any provider can peer with ony other provider bilaterally
> as he likes, if he has finally found out which VPN or other bi-lateral
> peering on Ip level he wants to use.
>
> [Daryl] Agreed.
>
> He could do this by interrogating his own local databases,
> (which he has to maintain by himself, spendig a lot of money and
> making a lot of mistakes) or he may interrogate a common global database
> e.g. the DNS (both for SRV and ENUM)
>
> [Daryl]  I think this is a little presumptuous, but is ultimately their
> choice.  If their choice is not to use DNS, then another more cost
> effective method may be used by the operator (i.e. think along the lines
> of class 4 switching), as long as it is within the specific environment
> (e.g. private/carrier peering...basically eliminates public peering if
> not DNS).
>
> I know that split horizon DNS may be used, but the drawback of
> this is that the DNS behind the curtain must be administrated by himself
>
> So the prime question in ENUM WG is where to place a globally
> reachable ENUM DNS and the question in speermint WG is what
> information has to be placed in the public DNS.
>
> [Daryl] I think this is the only method capable of supporting a public
> peering model.
>
> Both can only be in the public address spece to be useful, and
> therefore everybody needs access to thsi address space.
>
> If they then do peering by whatever means on l3, so they could
>
> Richard
>
> ________________________________
>
> Von: Malas, Daryl [mailto:[email-masked]]
> Gesendet: Di 04.04.2006 19:09
> An: Stastny Richard; Hadriel Kaplan; Patrick Melampy; Reinaldo Penno;
> [email-masked]
> Betreff: RE: [Speermint] Reachability
>
>
>
> Okay, I apologize for jumping into the middle of this, but I wanted to
> add my two cents.  I think by now it should be generally understood, if
> you want to interconnect with non-RFC1918 address spaces; you need to
> utilize a method (any number of options, such as STUN, B2BUA,
> etc...etc...)in order to be addressable and routable on the public
> registered address space.  This being said, I think peering will be
> applicable in 3 different environments:
>
> 1.  Public peering (somehow connected and routable by the public
> internet)
>         a.  Public addressable space
>         b.  Routed across the public internet
>         c.  Media and signaling accessible from the public internet
>                 1.  May be encrypted for privacy reasons
>                 2.  Authentication mechanisms likely in place
> 2.  Private peering (either public addresses (non-routable to the
> internet) or RFC1918 address space)
>         a.  Public address space -- not routed via the Internet
>         b.  RFC1918 address space -- non-NAT req'd
>         c.  Little or no security likely implemented
>         d.  Not accessible from the public internet (may be accomplished
> by          private tunnels l2TP, PPTP, IPSEC, etc.)
> 3.  Carrier peering (l2vpn or l3vpn between carriers utilizing RFC1918
> or non-RFC1918 address space as necessary)
>         a.  Utilizes public or private addresses
>         b.  Intended capabilities such as l2vpn or l3vpn for
> interconnection
>         c.  Media and signaling are not accessible from the public
> internet
>         d.  Primarily intended for peering between carriers as opposed
> to          enterprises (this might include "Federations" depending on
> def.).
>
> Does it make sense to break up the issues/requirements based on these 3
> different environments?
>
> Daryl M.
>
> -----Original Message-----
> From: Stastny Richard [mailto:[email-masked]]
> Sent: Tuesday, April 04, 2006 10:45 AM
> To: Hadriel Kaplan; Patrick Melampy; Reinaldo Penno; [email-masked]
> Subject: Re: [Speermint] Reachability
>
> >Most consumers on the planet Earth are in private address spaces at
> this
> >point I think (i.e., 192.168.x.x), and many Enterprises are as well.
> Entire
> >networks in some countries are privately addressed, yet they are
> members of,
> >and use, the Internet.
>
> Yes, but if you put your mailserver  only in 192.168.x.x, you will get a
> problem
>
> Richard
>
> ________________________________
>
> Von: Hadriel Kaplan [mailto:[email-masked]]
> Gesendet: Di 04.04.2006 18:22
> An: Stastny Richard; 'Patrick Melampy'; 'Reinaldo Penno';
> [email-masked]
> Betreff: RE: [Speermint] Reachability
>
>
>
> Hi Richard,
> And here we get to the fun stuff.  :)
>
> The idea of every serving proxy/registrar/sip-node needing to be
> publicly
> addressable is neither an Internet requirement, nor a requirement of the
> IETF.  Entire working groups in the IETF concern themselves with
> allowing,
> enabling, and inter-working private address spaces and VPNs.  What's
> missing
> is how to join them at the application and transport layer, when that
> application layer embeds addressing in itself.
>
> Most consumers on the planet Earth are in private address spaces at this
> point I think (i.e., 192.168.x.x), and many Enterprises are as well.
> Entire
> networks in some countries are privately addressed, yet they are members
> of,
> and use, the Internet.  There are also now 2 disjoint address groups
> defined
> by the IETF, as you know: IPv4 and IPv6.  There are mechanisms to try to
> provide interoperation/migration support for them, but that typically
> requires intermediaries.
>
> So I agree with you there needs to be an entity providing an ingress
> (and
> egress) point(s), either on the public network for it to be public, or
> for
> it to cross into another private address domain.  For this WG's purpose,
> I
> recommend we allow either model to work, as well as the model of the
> private
> going to public (and vice-versa) so long as the peering element of both
> sides are in the same public or private space.
>
> -Hadriel
>
>
> > -----Original Message-----
> > From: Stastny Richard [mailto:[email-masked]]
> > Sent: Tuesday, April 04, 2006 9:55 AM
> > To: Patrick Melampy; Reinaldo Penno; Hadriel Kaplan;
> [email-masked]
> > Subject: Re: [Speermint] Reachability
> >
> > >The conclusion here -- every endpoint and every serving
> proxy/registrar
> > >needs to be publicly addressable.
> >
> > This was my basic assumption, and I seemed not so clear to everybody.
> > This was also why I had a problem with Sohel's presentation at the
> IETF,
> > because I did not see any public adressable entities AT ALL.
> >
> > For the avoidance of doubt: I have no problem if the same peering
> > principles we develop here are used between some entities in a private
> > network,
> > but it is not out task to consider this separately. Because if it
> works
> > on the Internet, it also works in a private network (extranet in this
> > case)
> > (see DNS). this private network may even use public IP adresses, but
> if
> > the
> > are not routable from the public Internet, they are could as well be
> > private
> > (example IPX)
> >
> > What never can work is a peering between one entity on the public
> network
> > and one on a private network. The private entities need at least to
> have
> > one
> > ingress element on the public network
> >
> > Richard
> >
> > ________________________________
> >
> > Von: Patrick Melampy [mailto:[email-masked]]
> > Gesendet: Di 04.04.2006 15:29
> > An: 'Reinaldo Penno'; 'Hadriel Kaplan'; [email-masked]
> > Betreff: 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
> >
>
>
>
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint

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

---

From: David Meyer <[email-masked]>
Date: Wed, 5 Apr 2006 14:16:24 -0700

> ENUM is out-of-scope in speermint, it is only providing eventaully inter alia the call routing data

	Yep.

> what is used to locate the next hop.

	Yes, and that is part of our work...

> RFC3263 implies somewhat the DNS

	Again, yes.

	Dave