Subject: RE: [midcom] More than one NAT in Network-friendlier Midcom

From: Eliot Lear <[email-masked]>
Date: Thu, 06 Dec 2001 22:31:48 -0800

I don't know if Sean is on the list, but he did in fact suggest precisely 
what you mentioned- use DNS SRV records.  This has several benefits and 
several problems.  The benefits are that you force consistency in DNS 
because you can't have a connection without it- that's also bad, by the 
way, but I'll get to that in a bit.  It also has a discovery benefit, in as 
much as you can have multiple records for multiple NATs within an 
administrative domain.  This gets tricky for concentric NAT but then I've 
always been of the opinion that if you are going to NAT *always* NAT into 
public space.  I also think that DNS *should* play much more of a role than 
it does today, so that you can more properly identify the actors, and not 
just a pool member.

Now the problems: as I alluded, placing a connectivity requirement on a 
functional DNS could lead to certain circular dependencies.  However, these 
dependencies already exist just about any CLIENT, today, and it would be 
the CLIENT that would have the problem.  Getting reverse lookups working 
would be amusing, to say the least, since you *really* want to resolve both 
the IP address, and the transport port into a name.  Caching semantics here 
are of concern, as well.  If the phone ends up listening for a brief period 
of time, when it stops you have a problem if your ttl > 0.  Lots of gotchas 
around this one...

One problem is the installed base, and that every protocol would have to 
make use of this record.  I'm also unsure of whether operationally DNS is 
up to this, especially if each phone needs to do lots of transactions 
(opening ports, closing ports, etc).  This to me is a bit unknown.  We've 
all seen Randy's presentation, and I can't fault Keith for worrying about 
what messes could get created, here.

Eliot

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

---

From: "Cedric Aoun" <[email-masked]>
Date: Fri, 7 Dec 2001 09:47:17 -0000

Keith,
point taken
I was just proposing a potential solution, Eliot mentioned some of the
encountered issues.
Thanks for your comment
Cedric
-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Friday, December 07, 2001 2:07 AM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Scott Brim'; midcom
Subject: Re: [midcom] More than one NAT in Network-friendlier Midcom

> Potentially the solution could use DNS SRV with an embedded DNS ALG on the
> service provider MBs.

please don't pollute DNS in an effort to try to solve the NAT problem.
NATs cause enough problems as it is without making DNS worse.

Keith

---

From: "Cedric Aoun" <[email-masked]>
Date: Fri, 7 Dec 2001 10:14:24 -0000

Eliot,
I agree with all your comments.the solution to the bind dynamics might be to
create static binds, but it's quite heavy to maintain.
I thought of the cable service provider case, not all of them provide
registered addresses to their subscribers. I noticed that many cable service
providers provide one private IP address, therefore some subscribers use
residential middleboxes. This is one of the exceptions where NAT is applied
twice on the packets.This is another scenario that has been troubling me.
One could say, why not provide more private addresses to the subscribers,
this has obvious operational issues for the ISP network. 

I'm thinking to do a more detailed analysis on the DNS SRV method impacts.
Any volunteers ?
To which Randy's presentation are you referring to?
thanks
Cedric

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]]
Sent: Friday, December 07, 2001 7:32 AM
To: Aoun, Cedric [QPD:MA01:EXCH]
Cc: 'Scott Brim'; midcom
Subject: RE: [midcom] More than one NAT in Network-friendlier Midcom

Eliot