Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt

[Emil Ivov <[e-mail]>]

Hey Tiru,

On 18.09.12, 14:07, Tirumaleswar Reddy (tireddy) wrote:
>> > The only reason I can think why ICE Mobility would fail and ICE
>> > restart succeed is because of Simultaneous Mobility
>> 
>> Well ... I might be missing something but it seems to me that the only
>> time it would succeed would be when there's a direct reachability
>> between the mobile node's new address and their correspondent.
>> 
>> This would be the case when the mobile node has moved into the same
>> NATed network as the correspondent, or when the correspondent has a
>> public address with no one to perform endpoint dependent filtering in
>> front of them.
>> 
>> In all other situations (which would likely represent the majority of
>> the cases) ICE mobility would fail and one would need to perform an ICE
>> restart.
>> 
>> Emil
>  
> Hi Emil,
>  
> Thanks for the review.
>  
> I have assumed that the other Mobile Device (Correspondent Node in this
> case) would include MOBILITY-SUPPORT only in the following cases :
> IPv6 Global Address,

And I insist, even with IPv6 there should be no that performs endpoint
dependent filtering in front of the CN. Many corporate firewalls would
not allow incoming traffic unless it has been initiated from the inside.
Just as they would for IPv4.

> Correspondent Node is behind Endpoint-Independent
> Mapping/Filtering NAT as recommended in RFC 4787.

While 4787 is quite adamant about avoiding endpoint dependent mapping
this is not the case for endpoint dependent filtering:

  RTF 4787, REQ-8: ... If a more stringent filtering behavior is most
  important, it is RECOMMENDED that a NAT have an "Address-Dependent
  Filtering" behavior.

That text aside, while one could hope that (at least in certain parts of
the world) a decent number of CNs would be behind a NAT with endpoint
independent mapping, it is very rare to see commercial deployments with
endpoint independent filtering.

> But to make it work in other scenarios where Correspondent Node(CN) is
> behind Address-Dependent Filtering/Mapping, CN can detect the NAT
> behavior using simple tests suggested in RFC 5780 and so not include
> MOBILITY-SUPPORT attribute.

That kind of diagnostics are extremely difficult to apply in practice
(which is one of the reasons for ICE to exist) and even if they weren't,
disabling ICE mobility for NATs with endpoint dependent filtering would
leave you with very few cases where one would be able to use it.

> [Even without ICE Mobility, if both Mobile devices are behind non-BEHAVE
> compliant NAT then ICE connectivity checks using host/server-reflexive
> candidates will fail and end up using UDP relay]

Well again, NATs with endpoint dependent filtering are totally fine with
4787 and they do work with server-reflexive addresses.

Cheers,
Emil

--
https://jitsi.org