Subject: [midcom] Service identifier in PRR

From: Tom Taylor <[email-masked]>
Date: Thu, 09 Oct 2003 22:05:59 -0400

When did the service parameter get added to the PRR request?  I think that's a 
mistake.  Either a given internal address space overlaps with the public space so 
that twice-NAT is required, or it does not.  In any event, the agent isn't going to 
know whether it needs twice vs. single NAT -- only the middlebox has the necessary 
information, in its configuration.

I'm wondering a bit about the external interface parameter in PRR.  It would only 
matter if the flow were going from one internal address space to another.  Surely 
address mapping on the public side is independent of which interface is being used. 
  I would assume (unless someone corrects me) that if a given interface can reach 
any public addresses it can reach and be reached by all of them, except under 
failure conditions.  (It just occurred to me that this is overly optimistic, since 
great swathes of public space are walled off by firewalls.  Oh, well, someone else 
can comment on how important it is to allow for the possibility that different 
interfaces reach different parts of public space.)

As a BTW, I notice that the current draft of the NAT MIB assumes that one end of 
every flow is in the public address space -- there seems to be no provision for 
internal A-to-internal B flows.

Tom Taylor

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

---

From: Martin Stiemerling <[email-masked]>
Date: Fri, 10 Oct 2003 12:24:32 +0200

Hi Tom,

--On Thursday, October 09, 2003 22:05:59 -0400 Tom Taylor 
<[email-masked]> wrote:

| When did the service parameter get added to the PRR request?  I think
| that's a mistake.  Either a given internal address space overlaps with
| the public space so that twice-NAT is required, or it does not.  In any
| event, the agent isn't going to know whether it needs twice vs. single
| NAT -- only the middlebox has the necessary information, in its
| configuration.

The service parameter was added to PRR on a request from Bop Penfield. He 
described middleboxes that have dual-character: Being traditional NAT and 
twice NAT in one box and the same time. Never have heard about that 
earlier, but these middleboxes seem to exist. The service of the middlebox 
can be choosen depending on the target.
|
| I'm wondering a bit about the external interface parameter in PRR.  It
| would only matter if the flow were going from one internal address space
| to another.  Surely address mapping on the public side is independent of
| which interface is being used.   I would assume (unless someone corrects
| me) that if a given interface can reach any public addresses it can reach
| and be reached by all of them, except under failure conditions.  (It just
| occurred to me that this is overly optimistic, since great swathes of
| public space are walled off by firewalls.  Oh, well, someone else can
| comment on how important it is to allow for the possibility that
| different interfaces reach different parts of public space.)

We added the external interface identifier on request of Pyda. He argued 
that without these parameters no real configuration could be done. Perhaps 
you are describing some good reasons (having the Internet divided into 
different 'reachability areas'.

Martin

|
| As a BTW, I notice that the current draft of the NAT MIB assumes that one
| end of every flow is in the public address space -- there seems to be no
| provision for internal A-to-internal B flows.
|
| Tom Taylor
|

Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
PGP Key at:        http://www.stiemerling.org/stiemerling_nec.gpg
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de