[LINK] There goes the neighbourhood...

[Kim Holburn]

As I said, all the examples you give are details of setting up calls, ip infrastructure discussing where to send packets.  Of course there will be IP addresses there.  This is where you would talk about these things.  Every email has IP numbers in the data.  Come on.

But in H323 every audio and video packet in an audio or video stream has the IP numbers in an internal header.  We're not talking ringing phones or redirecting calls here.  

On 2011/May/12, at 4:27 PM, Paul Brooks wrote:

> On 12/05/2011 8:09 AM, Kim Holburn wrote:
>> 
>>> 
>>> SIP has the capability to 'fork' the audio path and have several handsets ring at
>>> once, and to transfer the call from one handset to another (please ignore the
>>> quaintness of the word 'handset' for the moment). Somehow, somewhere one host has to
>>> tell another host 'don't send anything back to me, send it over THERE - and THERE and
>>> THERE' - the moment you have to indicate 'THERE, NOT ME' you have to embed an address
>>> in a data field.
>> This would be a great thing in a completely open network but that's not what we have these days.  And it might be fine in a large corporate network but that's not where the main use is, is it.  the main use of SIP would be communicating across the random internet, and across firewalls.
> 
> Kim, it seems to me you are trying very hard to miss the point. SIP is a specific
> example, but there are many others of the generic need in a protocol to refer to a
> third host that is neither the originator or the destination of the packet - a host
> whos IP address does not appear in the IP packet header.
> 
> And yes, the example is for the real world, where an inbound SIP call should be able
> to make your desk phone, mobile phone, and softphone on the laptop ring so you can
> answer whichever one happens to be handy, especially when they are scattered across
> half a hemisphere. Through firewalls. Through a secure but transparent Internet that
> doesn't screw around with the packet contents. You need to embed IP addresses inside
> packet data fields for complex functionality to happen. And for that, we have to
> eliminate NAT.
> 
> Eliminating NAT does not reduce security, firewall function, or increase/decrease how
> IP addresses might be associated with an individual for device for tracking purposes.
> This last one seems to be important to you.

We talked about that already on link and we don't need to revisit it really.  In theory that is true.  When we talk about easily installed consumer routers, well, we'll just have to see.

>>> Its not just higher-order protocols - heck even the ICMP REDIRECT message has to have
>>> an IP address embedded in the data field.
>> Yes, a good example, and do you think ICMP REDIRECT has a place in a well managed network?  I remember using it once in a difficult migration.  All the windows machines ignored it - as they should.  It's a thing from the past.
> 
> I disagree. All well-managed networks should have at least two independent paths in
> and out of the network. Two routers. You could use something like VRRP to make them
> seem to have the same IP address, or you can just have them with different IP
> addresses and let ICMP REDIRECT optimise the correct exit point. VRRP was a kludge to
> provide availability for broken hosts that don't listen to ICMP REDIRECT - and I doubt
> I'm the only one here that feels that just because Windows devices ignored them,
> doesn't mean the Windows devices aren't broken.
> 
> (This is probably belonging more on AusNOG than LINK,  but what they hey.)

-- 
Kim Holburn
IT Network & Security Consultant
T: +61 2 61402408  M: +61 404072753
mailto:kim at holburn.net  aim://kimholburn
skype://kholburn - PGP Public Key on request