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

Emil Ivov <> Tue, 18 September 2012 12:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D25121E80C1 for <>; Tue, 18 Sep 2012 05:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JrKYL5G1oVdY for <>; Tue, 18 Sep 2012 05:49:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1EA4C21F8766 for <>; Tue, 18 Sep 2012 05:49:50 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so4208203wgb.13 for <>; Tue, 18 Sep 2012 05:49:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=3eKTh8IwJjJoM33hRUTAY7q0WUqJIyo3Ez7dBPn6uqM=; b=GgyaO725EegtVvJfxH4t/k1aLd7+tSql2R0fVXZ2FEi8A44Vi94qrqvekM2lVLs1K4 QtzNYIcQG5YCyU2kxNAMWcnaUfNjeELRLcd4DEHvDJdMDHCCbcVPBqoqZ5g+rXuQF78O gDeR6i70gQ9w3HhT0QujzHXc4yLU2hEHlH8t4tkWNHc6vfCq3NjQICWkKdNuO7faQEKm bydu0vqoF7nUSHwdrBxiEtNy7Cuih/4U/8NbA6v/CouJAJuRm9RnlwoRtjQwf5HSJoBW zpZ6h3XgKQCGeJZMuRHQDcJM4BA90/fwbhXI6TsB7VrmYk3JvFkVoOVFFs10wAjVm5eb crPA==
Received: by with SMTP id ca1mr23185872wib.8.1347972590108; Tue, 18 Sep 2012 05:49:50 -0700 (PDT)
Received: from ([2001:660:4701:1001:6d9e:5cc0:90cb:9fbb]) by with ESMTPS id j6sm31736591wiy.4.2012. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 05:49:44 -0700 (PDT)
Message-ID: <>
Date: Tue, 18 Sep 2012 14:49:44 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: "Tirumaleswar Reddy (tireddy)" <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQl1COql64ZjBgHJYHdvJ7gIiomiddf6GfhqWrVsp2hP0295mdtyzADBfGZGBVKoChNH8Ve0
Cc: "Prashanth Patil (praspati)" <>, "" <>, "Dan Wing (dwing)" <>
Subject: Re: [MMUSIC] New Version Notification for draft-wing-mmusic-ice-mobility-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Sep 2012 12:49:52 -0000

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

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.