• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Airport NAT behavior
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Airport NAT behavior


  • Subject: Re: Airport NAT behavior
  • From: Duane Murphy <email@hidden>
  • Date: Mon, 27 Mar 2006 18:42:41 -0800

Have you looked at STUN (RFC 3489)? It seems to solve some of these
problems, but it does require at least one end to have a fixed address,
ie to be a server. Once connected, STUN keeps the paths open through as
many NATs as you can throw at it.

<http://www.ietf.org/rfc/rfc3489.txt>

--- At Mon, 27 Mar 2006 17:57:41 -0800, Tim Dorcey wrote:

>> might be remembering wrong.  Does anybody have anymore details on
>> this, especially instructions for making the 1:1 request, and if it
>> requires admin privileges on either the computer or router?
>
>See http://files.dns-sd.org/draft-chesire-nat-pmp.txt
>
>The protocol is simple and to the point, so should be easy enough to code
>manually if Apple does not provide client-side API.  I would doubt any admin
>privileges would be required, though I could imagine there might be a switch
>on the Airport admin interface to disable it.
>
>Now, what would be really cool is if the Airport supported a slight
>modification to the PMP protocol, as follows:
>
>1.  There would be an automatic gateway routing mechanism, so the client
>software doesn't neeed to learn the actual IP address of the Airport.
>
>2.  Instead of opening a port for anyone outside to use, a message to the
>Airport would be able to specify a particular remote (addr,port) that is
>allowed to come in for some fixed period of time until a timeout expired.
>
>3.  Instead of sending back the port mapping to the local client, the
>Airport would forward the port mapping to the remote (addr,port) that is to
>be allowed in
>
>4.  There would be an option to include some application payload data on
>this message, that would be delivered to the remote (addr,port) along with
>the port mapping.
>
>I would call it UDP :-).
>
>I guess if the Airport worked this way, then we might need a special
>protocol to instruct it when we want it to use a different port for each
>connection.  Oh, wait, a process is already allowed to open multiple UDP
>ports on a local host whenever it wishes to be seen at multiple ports.
>
>Anyway, support for PMP is a great step forward.  It will allow the Airport
>user to interact with other users who are behind broken NAT's, just as if
>the Airport user had a public IP.
>

 ...Duane
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • RE: Airport NAT behavior
      • From: "Tim Dorcey" <email@hidden>
References: 
 >Re: Airport NAT behavior (From: email@hidden)
 >RE: Airport NAT behavior (From: "Tim Dorcey" <email@hidden>)

  • Prev by Date: kCFStreamPropertyHTTPAttemptPersistentConnection
  • Next by Date: RE: Airport NAT behavior
  • Previous by thread: RE: Airport NAT behavior
  • Next by thread: RE: Airport NAT behavior
  • Index(es):
    • Date
    • Thread