[arin-ppml] IPv6 Non-connected networks

Chris Engel cengel at sponsordirect.com
Fri Mar 26 17:02:18 EDT 2010

Owen Delong wrote:

> However, at the far end when I'm trying to figure out why something
> didn't
> work, any of the following behaviors related to NAT make things more
> difficult to debug:
> 1.    RTP packet sourced from 10.x not translated and dropped
> by outbound
>       firewall because outbound firewall doesn't handle SIP/RTP well.
> 2.    RTP packet sourced from 10.x leaks onto network and gets dropped
>       later.
> (1 and 2 mean I never see the RTP packet at my side, so, WTF?
> I have no
> idea what happened to it and no easy way to know whether it's a NAT
> issue or something else dropping my customer's traffic)

Not to sound like the village idiot here... and I probably will since I have ZERO experience with VOIP protocols.... but how would this be qualitatevly different from the Remote Admin having a filter rule on his Firewall that silently drops such traffic anyway?

I mean, if you aren't getting any traffic through...it's not like you would (in the absence of NAT) have this crystal ball that tells you WHY that traffic isn't getting through. Other then some very basic tests say for general internet connecivity and maybe a tracert to your IP... I would think you'd pretty much HAVE to contact the Admin on the other side of things to work out the issue.

Speaking as an Enterprise Admin... I don't WANT any traffic crossing my network boundary that I haven't specificaly setup mechanisms to allow. I also don't WANT any of my end users working with some outside Tech trying to route something through my Firewall that I haven't specificaly setup and approved.... in fact, around here we consider that kinda a "firing offense" (pretty common rule in Enterprises).

The way a scenerio like that would go down if it happaned here would be:

1) You'd call up one of my end users to try to figure out why the connection wasn't getting through.

2) They (if they listened to thier training at all) would conference me or one of my staff in to help "resolve" the issue.

3) We would inform you (and them) that what you were trying to hookup wasn't a "Supported Application" on our network and therefore wasn't allowed... and wish you a nice day.

4) I would then point out to said end user, the section of the security policy which they signed that covers the procedure for requesting new applications/functionality.

5) Thier supervisor would have a nice private chat with them.

The whole thing shouldn't take more then 10-15 minutes of time.... and certainly shouldn't involve much pain on your end.

Christopher Engel

More information about the ARIN-PPML mailing list