tag, you can have zero or more ,

, or tags, followed by zero or more

tags. The numbers indicate the line and column number where the error was noticed, but that number is figured out after include and reference processing has been performed. So it may not match exactly the line numbering in your file, but should be close. 2) Turn off the strict checking. In the web form, on the line that says Checking, instead of picking Strict choose Fast. Note that there is currently an effort to rewrite the xml2rfc processor that does the actual processing behind the scenes. One of the requirements for this effort was that it pay strict attention to the DTD, exactly like the Strict Checking does. Hope this helps. Tony Hansen tony@att.om From paul.hoffman@vpnc.org Thu Apr 21 13:19:20 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 017B3E06B9 for ; Thu, 21 Apr 2011 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33gcYZuftwlB for ; Thu, 21 Apr 2011 13:19:19 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id 5E9C8E07B6 for ; Thu, 21 Apr 2011 13:19:19 -0700 (PDT) Received: from sn80.proper.com (sn80.proper.com [75.101.18.80]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3LKJHkC013408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 21 Apr 2011 13:19:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2011 13:19:17 -0700 Message-Id: <58791AC4-5B5C-4B64-8378-EA00C1E6F4AA@vpnc.org> To: Tools Team Discussion Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Tools-discuss] A draft that didn't get announced: draft-hoffman-rfc3536bis-02 X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:19:20 -0000 Greetings again. I turned in draft-hoffman-rfc3536bis-02 earlier today. = It appears on the tools site, but it never got announced on = i-d-announce. Is there a possibility that this is because I turned it in = with the new tool and/or because it was unpaginated? --Paul Hoffman From esanchez@yaco.es Mon Apr 25 09:04:35 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5B0B6E06A9 for ; Mon, 25 Apr 2011 09:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.817 X-Spam-Level: X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuPj64ZyyCih for ; Mon, 25 Apr 2011 09:04:34 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfc.amsl.com (Postfix) with ESMTP id 81C16E0758 for ; Mon, 25 Apr 2011 09:04:34 -0700 (PDT) Received: by wwk4 with SMTP id 4so1450041wwk.1 for ; Mon, 25 Apr 2011 09:04:33 -0700 (PDT) Received: by 10.227.148.144 with SMTP id p16mr4243386wbv.223.1303747473509; Mon, 25 Apr 2011 09:04:33 -0700 (PDT) Received: from [192.168.0.197] ([77.227.215.107]) by mx.google.com with ESMTPS id w25sm3336592wbd.22.2011.04.25.09.04.27 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 09:04:27 -0700 (PDT) Message-ID: <4DB59B8F.7010509@yaco.es> Date: Mon, 25 Apr 2011 18:04:31 +0200 From: =?ISO-8859-1?Q?=22Emilio_A=2E_S=E1nchez=22?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <58791AC4-5B5C-4B64-8378-EA00C1E6F4AA@vpnc.org> In-Reply-To: <58791AC4-5B5C-4B64-8378-EA00C1E6F4AA@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Tools-discuss] A draft that didn't get announced: draft-hoffman-rfc3536bis-02 X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:04:35 -0000 Hi Paul, I'm reviewing the code of the new tool and it seems that it is not creating announcements for new submissions. I created ticket #649 [1] to solve this problem. I'm working to fix it, I'll inform you as soon as it's solved. Thanks for the report. [1] http://trac.tools.ietf.org/tools/ietfdb/ticket/649 El 21/04/11 22:19, Paul Hoffman escribi�: > Greetings again. I turned in draft-hoffman-rfc3536bis-02 earlier today. It appears on the tools site, but it never got announced on i-d-announce. Is there a possibility that this is because I turned it in with the new tool and/or because it was unpaginated? > > --Paul Hoffman > > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From evnikita2@gmail.com Mon Apr 25 09:20:10 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3D382E0750 for ; Mon, 25 Apr 2011 09:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy6IBFuc+RxH for ; Mon, 25 Apr 2011 09:20:09 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 0D678E075C for ; Mon, 25 Apr 2011 09:20:08 -0700 (PDT) Received: by fxm15 with SMTP id 15so1715934fxm.31 for ; Mon, 25 Apr 2011 09:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=gyrBWI/64LE893K+8DVGf0LjcN3vb+Mr6BFaS/1I3Vk=; b=LV4+CykCAJgDjPTX6Ei5zDjc6OEywyapXIp1LPRT1FrGUnGIGSfDeO8z1XaOhvbjR+ p/33BdaqjfLyb6UhDzfKqnKjDNIMHHLJLw9llmkjta90xqNAmntCLj8X608bBBuUP/+k VflN1iTjdrySoIOMBTAndt3RNNRi97J/TXON4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=l0Cif3F4IP/hDMdSEVUDHu21XRL2EVYAmSEe10V+WjvWHbtHc9xSHrxEtI/QUcPGmI nC8wi2IOyffLhOQPYsHff5jJCTKpVbY3Dm0gf9TLHVE4zFalmLxxwj2btvneU7LMMHR9 +e4Ky2XUUR24mDfCAnWNysvFIQPIHizfKzpho= Received: by 10.223.17.141 with SMTP id s13mr269268faa.23.1303748408425; Mon, 25 Apr 2011 09:20:08 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id t2sm1728959faa.23.2011.04.25.09.20.07 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 09:20:07 -0700 (PDT) Message-ID: <4DB59F62.9000701@gmail.com> Date: Mon, 25 Apr 2011 19:20:50 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tools-discuss@ietf.org Content-Type: multipart/alternative; boundary="------------050702010705030101020701" Subject: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:20:10 -0000 This is a multi-part message in MIME format. --------------050702010705030101020701 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, This page: http://tools.ietf.org/html/draft-faltstrom-5892bis-04 in its 'header' has a mention of this draft obsoleting RFC 5892. Yes, it is in the draft's name, but the draft actually has no such regulation. I think there is a minor problem in rfcmarkup tool with this issue that, IMO, should be corrected. This may make the reader a bit confused. Mykyta Yevstifeyev --------------050702010705030101020701 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello,

This page:

http://tools.ietf.org/html/draft-faltstrom-5892bis-04

in its 'header' has a mention of this draft obsoleting RFC 5892. Yes, it is in the draft's name, but the draft actually has no such regulation.

I think there is a minor problem in rfcmarkup tool with this issue that, IMO, should be corrected. This may make the reader a bit confused.

Mykyta Yevstifeyev
--------------050702010705030101020701-- From paul.hoffman@vpnc.org Mon Apr 25 09:32:36 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1C5F2E06A9 for ; Mon, 25 Apr 2011 09:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.073 X-Spam-Level: X-Spam-Status: No, score=-102.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3LGbxlLccts for ; Mon, 25 Apr 2011 09:32:35 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id 26355E0664 for ; Mon, 25 Apr 2011 09:32:35 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3PGWV3w095993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Apr 2011 09:32:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DB59F62.9000701@gmail.com> Date: Mon, 25 Apr 2011 09:32:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <873E42F0-8158-4880-BBB4-6A94EF1CCAC6@vpnc.org> References: <4DB59F62.9000701@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:32:36 -0000 On Apr 25, 2011, at 9:20 AM, Mykyta Yevstifeyev wrote: > Hello, >=20 > This page: >=20 > http://tools.ietf.org/html/draft-faltstrom-5892bis-04 >=20 > in its 'header' has a mention of this draft obsoleting RFC 5892. =20 The header that I see doesn't say anything about "obsoleting". Where do = you see that word? In the view I see, it lists RFC 5892 as an earlier = version, which is a reasonable guess. --Paul Hoffman From bob.hinden@gmail.com Mon Apr 25 09:34:44 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 08673E06CC for ; Mon, 25 Apr 2011 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.613 X-Spam-Level: X-Spam-Status: No, score=-103.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKG74YZ5U0XS for ; Mon, 25 Apr 2011 09:34:43 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 2EB72E06A9 for ; Mon, 25 Apr 2011 09:34:43 -0700 (PDT) Received: by pwi5 with SMTP id 5so1775645pwi.31 for ; Mon, 25 Apr 2011 09:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=C/sfHffGznfHGHvQNxROgtbQZzY5RXz36+iB5Oechyk=; b=k6GPebYmd0njTs0Y97q2Zg3PBy4MUEZgHlQwqx/i/olQVM9KYGOxP2Uav7572faeqm uQcXRbf6eQhqJ4Y1VWPjkCFGKTT1gyAl9TEzK4j/9GJIdXhTMM6T3gfktDSTK0msx7nG 1orV+CC8m9+zSONTbGl1DoHj2zA8Sozdwy9xA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=G60+QsCtUbbpbYUsbk5QsAQNji/7164iFsa4A7XVKcAWbQa1aiXXsLiChtK/uQXPYY C+x5aZIG/qKuZFxhvYP2d2f3MAeJwvbstgXl6WrUE3CXu7R2VV01hn2enq0Bo3ssljPO pRgH03Un+5bqLC3hi2KuMVCZY2A20TRK24uCs= Received: by 10.142.78.12 with SMTP id a12mr2628471wfb.268.1303749282426; Mon, 25 Apr 2011 09:34:42 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id s39sm7962703wfc.4.2011.04.25.09.34.40 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 09:34:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4DB59F62.9000701@gmail.com> Date: Mon, 25 Apr 2011 09:34:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB59F62.9000701@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 16:34:44 -0000 Mykyta, On Apr 25, 2011, at 9:20 AM, Mykyta Yevstifeyev wrote: > Hello, >=20 > This page: >=20 > http://tools.ietf.org/html/draft-faltstrom-5892bis-04 >=20 > in its 'header' has a mention of this draft obsoleting RFC 5892. Yes, = it is in the draft's name, but the draft actually has no such = regulation.=20 Read the last sentence of the abstract: > This document specifies IETF consensus for IDNA derived character > properties related to the three code points, existing in Unicode = 5.2, > that changed property values when version 6.0 was released. The > consensus is that no update is needed to RFC 5892 based on the > changes made in Unicode 6.0. Also, Section 2. of the draft. I don't think there is a tool problem here. Bob >=20 > I think there is a minor problem in rfcmarkup tool with this issue = that, IMO, should be corrected. This may make the reader a bit = confused. >=20 > Mykyta Yevstifeyev > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From evnikita2@gmail.com Mon Apr 25 10:07:52 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 20893E0783 for ; Mon, 25 Apr 2011 10:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZrUAUmSZK9Z for ; Mon, 25 Apr 2011 10:07:51 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 43D41E0781 for ; Mon, 25 Apr 2011 10:07:51 -0700 (PDT) Received: by fxm15 with SMTP id 15so1748267fxm.31 for ; Mon, 25 Apr 2011 10:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ClfwfGkZMXMBCUzzlw1ISYf5CwRkOud5nHqADd6fK5c=; b=CPfuQIT/ANIaAJ5LFPqgOb11IFwweVTQcuke9ZydUmFxXxoiOr1B4/sqN+QlKZSJvj 8CfwPPAwy8y+TFtgTUROjIG57c7TJSBxh9ddRHQXn0PyQ7+NL7Cp05itI2ItxAwrw7Zb sYJ/lqWa2nPM/jyBGd5QJgSTzf4kToyZH/F5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bOTiynOEPW/wRtdQcil6LYB1tE2XOrjij4fIi22LBgFaG3tPEb4yOZlRiYFYfK1lbb b2KC5uu78SbizHiRxW8GNAqLYg2k6o+5Of2NQeMG42KPJ5xwR5gAQyLSr4wT7Cm7yI82 Llc3ar9ES8BVopX6EvvyTsa2lx9RyDndPK5zo= Received: by 10.223.55.201 with SMTP id v9mr48765fag.76.1303751270506; Mon, 25 Apr 2011 10:07:50 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id n9sm1740803fax.3.2011.04.25.10.07.49 (version=SSLv3 cipher=OTHER); Mon, 25 Apr 2011 10:07:49 -0700 (PDT) Message-ID: <4DB5AA90.8090204@gmail.com> Date: Mon, 25 Apr 2011 20:08:32 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Hoffman References: <4DB59F62.9000701@gmail.com> <873E42F0-8158-4880-BBB4-6A94EF1CCAC6@vpnc.org> In-Reply-To: <873E42F0-8158-4880-BBB4-6A94EF1CCAC6@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 17:07:52 -0000 25.04.2011 19:32, Paul Hoffman wrote: > On Apr 25, 2011, at 9:20 AM, Mykyta Yevstifeyev wrote: > >> Hello, >> >> This page: >> >> http://tools.ietf.org/html/draft-faltstrom-5892bis-04 >> >> in its 'header' has a mention of this draft obsoleting RFC 5892. > The header that I see doesn't say anything about "obsoleting". Where do you see that word? In the view I see, it lists RFC 5892 as an earlier version, which is a reasonable guess. The (RFCnnnn) occurs when there is a "Obsoletes: nnnn" in the header, like http://tools.ietf.org/html/draft-yevstifeyev-rfc862bis-echo-01. In this case there is no any mention like this in the draft. rfcmarkup added this because there is 5892bis in the name; the draft actually does not perform such action. This is what I'm pointing to - such behavior is caused by the name, but not the actual contents. Mykyta Yevstifeyev > --Paul Hoffman > > From bob.hinden@gmail.com Mon Apr 25 10:21:10 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 80280E06E1 for ; Mon, 25 Apr 2011 10:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.612 X-Spam-Level: X-Spam-Status: No, score=-103.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqLOsLVUwQPT for ; Mon, 25 Apr 2011 10:21:09 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfc.amsl.com (Postfix) with ESMTP id 653D2E06A7 for ; Mon, 25 Apr 2011 10:21:09 -0700 (PDT) Received: by pwi5 with SMTP id 5so1807058pwi.31 for ; Mon, 25 Apr 2011 10:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=2Bse4Y+dnspTpkQixnaEhfrRxDg5eWgidQmwwdDLNcE=; b=S2IAm/GOQWxxPtG1QmsvxWPNg1S7Cs3Umg4FEsJvrIcyFBCRMggoy2OvPOYqwvYRrS tkYfGMrhDHNlreA0aSzZhIITYRJNjDt4mQ1Nm9W48zTK6T7iO7Fx7NdE+c3FPSEfFqNy RBzi0JfoC5b40PPujWIe1YjH16BSnOEgbGBuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=rBy41AOUID7uiDRRnCXyu9+a+GEQmZOQ64TMjykmMpqsjg6cBUSp3QkvSdNwwApvQ6 I8yThAu03o0WGt5HHqeDOh/8MKX5X9T3AGYiiIYmFndEQgqUSTcIeJgTLIoWKID/+9yc 7zPCh27WO7ltQsP5HA9KoVvw/BdBwPyMHSZGI= Received: by 10.68.59.1 with SMTP id v1mr6999263pbq.291.1303752063771; Mon, 25 Apr 2011 10:21:03 -0700 (PDT) Received: from [10.0.0.37] (c-24-130-225-13.hsd1.ca.comcast.net [24.130.225.13]) by mx.google.com with ESMTPS id d9sm4018428pba.16.2011.04.25.10.21.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Apr 2011 10:21:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <4DB5AA90.8090204@gmail.com> Date: Mon, 25 Apr 2011 10:20:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5E9C3C1A-47BB-4568-88A0-2DC81C3D5AA8@gmail.com> References: <4DB59F62.9000701@gmail.com> <873E42F0-8158-4880-BBB4-6A94EF1CCAC6@vpnc.org> <4DB5AA90.8090204@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: Paul Hoffman , tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 17:21:10 -0000 On Apr 25, 2011, at 10:08 AM, Mykyta Yevstifeyev wrote: > 25.04.2011 19:32, Paul Hoffman wrote: >> On Apr 25, 2011, at 9:20 AM, Mykyta Yevstifeyev wrote: >>=20 >>> Hello, >>>=20 >>> This page: >>>=20 >>> http://tools.ietf.org/html/draft-faltstrom-5892bis-04 >>>=20 >>> in its 'header' has a mention of this draft obsoleting RFC 5892. >> The header that I see doesn't say anything about "obsoleting". Where = do you see that word? In the view I see, it lists RFC 5892 as an earlier = version, which is a reasonable guess. > The (RFCnnnn) occurs when there is a "Obsoletes: nnnn" in the header, = like http://tools.ietf.org/html/draft-yevstifeyev-rfc862bis-echo-01. In = this case there is no any mention like this in the draft. rfcmarkup = added this because there is 5892bis in the name; the draft actually does = not perform such action. This is what I'm pointing to - such behavior = is caused by the name, but not the actual contents. OK, but I don't see "Obsoletes:" in any headers? Bob >=20 > Mykyta Yevstifeyev >> --Paul Hoffman >>=20 >>=20 >=20 > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From paul.hoffman@vpnc.org Mon Apr 25 10:23:23 2011 Return-Path: X-Original-To: tools-discuss@ietfc.amsl.com Delivered-To: tools-discuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C5A00E06E1 for ; Mon, 25 Apr 2011 10:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.081 X-Spam-Level: X-Spam-Status: No, score=-102.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxZmEzbGpGQ6 for ; Mon, 25 Apr 2011 10:23:22 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id A2858E073F for ; Mon, 25 Apr 2011 10:23:22 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3PHNKhP098873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Apr 2011 10:23:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DB5AA90.8090204@gmail.com> Date: Mon, 25 Apr 2011 10:23:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <36335E21-A951-40A9-9D90-266AB416D545@vpnc.org> References: <4DB59F62.9000701@gmail.com> <873E42F0-8158-4880-BBB4-6A94EF1CCAC6@vpnc.org> <4DB5AA90.8090204@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 17:23:23 -0000 On Apr 25, 2011, at 10:08 AM, Mykyta Yevstifeyev wrote: > 25.04.2011 19:32, Paul Hoffman wrote: >> On Apr 25, 2011, at 9:20 AM, Mykyta Yevstifeyev wrote: >>=20 >>> Hello, >>>=20 >>> This page: >>>=20 >>> http://tools.ietf.org/html/draft-faltstrom-5892bis-04 >>>=20 >>> in its 'header' has a mention of this draft obsoleting RFC 5892. >> The header that I see doesn't say anything about "obsoleting". Where = do you see that word? In the view I see, it lists RFC 5892 as an earlier = version, which is a reasonable guess. > The (RFCnnnn) occurs when there is a "Obsoletes: nnnn" in the header, = like http://tools.ietf.org/html/draft-yevstifeyev-rfc862bis-echo-01. You did not answer my question. You said "in its 'header' has a mention = of this draft obsoleting RFC 5892". I believe that statement is wrong. = The fact that the (RFCnnnn) appears for some draft doesn't mean that = reason applies to every draft. > In this case there is no any mention like this in the draft. = rfcmarkup added this because there is 5892bis in the name; the draft = actually does not perform such action. This is what I'm pointing to - = such behavior is caused by the name, but not the actual contents. And many of us would consider that a good thing. You are complaining = about a useful feature by stating something untrue about it. --Paul Hoffman From patrik@frobbit.se Mon Apr 25 21:43:45 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37827E06BE for ; Mon, 25 Apr 2011 21:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RIR2EKWYN5n for ; Mon, 25 Apr 2011 21:43:40 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 7948EE06A0 for ; Mon, 25 Apr 2011 21:43:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 24D481090BE81; Tue, 26 Apr 2011 06:43:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3NaxglzX0Yt; Tue, 26 Apr 2011 06:43:37 +0200 (CEST) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 9B21E1090BE75; Tue, 26 Apr 2011 06:43:37 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4DB59F62.9000701@gmail.com> Date: Tue, 26 Apr 2011 06:43:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <198D2050-3684-4087-B49B-4AC3DBD183B7@frobbit.se> References: <4DB59F62.9000701@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:43:45 -0000 On 25 apr 2011, at 18.20, Mykyta Yevstifeyev wrote: > in its 'header' has a mention of this draft obsoleting RFC 5892. Yes, = it is in the draft's name, but the draft actually has no such = regulation. No, as other people say it references that RFC, as in updating or = obsoleting or.... It does not say anything about obsoleting RFC 5892. Patrik From dwing@cisco.com Mon Apr 25 21:56:31 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B4EE067C for ; Mon, 25 Apr 2011 21:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYTt-bw8nRjn for ; Mon, 25 Apr 2011 21:56:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id D0A78E06D0 for ; Mon, 25 Apr 2011 21:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3527; q=dns/txt; s=iport; t=1303793790; x=1305003390; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Cu5Pvlg4YGUtoCXDL+imPFrORPAs8LCbeWNG4GsfB7Y=; b=Y3g5DoVyHC9oLT/cfW2VFpVuu83/FbPssGsfifbRsp1dpqeqyB7s8v8I z9MuKPFKcw9HyxH2rzeey9EzKuE/zgABohXPvL5TAJQTU1wt4o8VR1Tde 4qRsUoH78ybRDOJJIEjHE7E1aoycyWGIh+CsHMXBIWhBT25JeIlC6LWct c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoBAIlPtk2rRDoJ/2dsb2JhbACXVoFji0Y9d4hwnx6PLQGNYYV2BIV3 X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="436270167" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 04:56:29 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q4uT6i009524; Tue, 26 Apr 2011 04:56:29 GMT From: "Dan Wing" To: "'Henrik Levkowetz'" , "'Mark Nottingham'" References: <20110322130123.GB12433@nic.fr> <4309FBC6-92C0-4072-8C9C-E54DCD19CBC4@mnot.net> <4D8DB09D.6040307@levkowetz.com> In-Reply-To: <4D8DB09D.6040307@levkowetz.com> Date: Mon, 25 Apr 2011 21:56:29 -0700 Message-ID: <04c801cc03ce$4e4fa310$eaeee930$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvrl6RXXuemgfDXTmyx6GVvSWBbTQYNoR6g Content-Language: en-us Cc: 'IETF TOOLS discussion' Subject: Re: [Tools-discuss] Fwd: [vixie@isc.org: googlebot to the rescue] X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 04:56:31 -0000 > -----Original Message----- > From: tools-discuss-bounces@ietf.org [mailto:tools-discuss- > bounces@ietf.org] On Behalf Of Henrik Levkowetz > Sent: Saturday, March 26, 2011 2:24 AM > To: Mark Nottingham > Cc: IETF TOOLS discussion > Subject: Re: [Tools-discuss] Fwd: [vixie@isc.org: googlebot to the > rescue] > > Hi, > > The new draft submission tool doesn't have this problem. Just now I used the new submission tool for the first time, and it also seemed to only need a GET to authorize the actual posting of the I-D. -d > I'm about to > start merging that code to the trunk of the datatracker svn repository > in something like 10 minutes from now, and do the first deployment > today. > > > Best, > > Henrik > > > > On 2011-03-23 00:25 Mark Nottingham said the following: > > In case this hasn't been seen -- it needs to be fixed (i.e., a GET > shouldn't have such side effects). > > > > Cheers, > > > > > > Begin forwarded message: > > > >> *Resent-From: *ietf-http-wg@w3.org > >> *From: *Stephane Bortzmeyer > > >> *Date: *23 March 2011 12:01:23 AM AEDT > >> *To: *HTTP Working Group wg@w3.org>> > >> *Subject: **[vixie@isc.org: googlebot to the rescue]* > >> *organization: *NIC France > >> *archived-at: * > >> > >> The draft management tool apparently can change the state of a draft > >> in response to a simple GET... > >> > >> Nice violation of the HTTP standard :-) > >> > >> *From: *Paul Vixie > > >> *Date: *19 March 2011 2:50:30 AM AEDT > >> *To: *dnsext@ietf.org > >> *Subject: **googlebot to the rescue* > >> > >> > >> i think the 0x20 draft was going nowhere in any case so cancelling > it is fine. > >> > >> 148.68.249.66.in-addr.arpa domain name pointer > >> crawl-66-249-68-148.googlebot.com 148.googlebot.com>. > >> > >> crawl-66-249-68-148.googlebot.com 148.googlebot.com> has address 66.249.68.148 > >> > >> it's interesting that it can be done by a web crawler, though. > >> > >> re: > >> > >> > >> *From: *IETF I-D Submission Tool > > >> *Date: *18 March 2011 10:36:25 PM AEDT > >> *To: *ipr@ietf.org , dagon@cc.gatech.edu > , vixie@isc.org > >> *Subject: **Submission of draft-vixie-dnsext-dns0x20-00 has been > Cancelled * > >> > >> > >> This message is to notify you that submission of an Internet-Draft, > draft-vixie-dnsext-dns0x20-00, has just been cancelled by a user whose > computer has an IP address of 66.249.68.148. > >> > >> The IETF Secretariat. > >> > >> > >> > >> _______________________________________________ > >> dnsext mailing list > >> dnsext@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsext > >> > >> > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > > > > > _______________________________________________ > > Tools-discuss mailing list > > Tools-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/tools-discuss > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss From henrik@levkowetz.com Tue Apr 26 05:58:58 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3A2E0758 for ; Tue, 26 Apr 2011 05:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB5x9tlBVg8Z for ; Tue, 26 Apr 2011 05:58:58 -0700 (PDT) Received: from merlot.tools.ietf.org (unknown [IPv6:2a01:3f0:0:31:214:22ff:fe21:bb]) by ietfa.amsl.com (Postfix) with ESMTP id C2979E0715 for ; Tue, 26 Apr 2011 05:58:57 -0700 (PDT) Received: from brunello.autonomica.se ([2a01:3f0:1:0:21e:c2ff:fe13:7e3e]:58515 helo=dyn-fg117.sth.netnod.se) by merlot.tools.ietf.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.75) (envelope-from ) id 1QEhqp-0002IW-7I; Tue, 26 Apr 2011 14:58:48 +0200 Message-ID: <4DB6C187.9040907@levkowetz.com> Date: Tue, 26 Apr 2011 14:58:47 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Dan Wing References: <20110322130123.GB12433@nic.fr> <4309FBC6-92C0-4072-8C9C-E54DCD19CBC4@mnot.net> <4D8DB09D.6040307@levkowetz.com> <04c801cc03ce$4e4fa310$eaeee930$@com> In-Reply-To: <04c801cc03ce$4e4fa310$eaeee930$@com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2a01:3f0:1:0:21e:c2ff:fe13:7e3e X-SA-Exim-Rcpt-To: dwing@cisco.com, mnot@mnot.net, tools-discuss@ietf.org, henrik-sent@levkowetz.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 22 Mar 2010 06:51:10 +0000) X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org) Cc: 'Mark Nottingham' , 'IETF TOOLS discussion' Subject: Re: [Tools-discuss] Fwd: [vixie@isc.org: googlebot to the rescue] X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 12:58:58 -0000 Hi Dan, Hmm. Ok. I'll get the developer to fix it. Thanks, and best regards, Henrik On 2011-04-26 06:56 Dan Wing said: >> -----Original Message----- >> From: tools-discuss-bounces@ietf.org [mailto:tools-discuss- >> bounces@ietf.org] On Behalf Of Henrik Levkowetz >> Sent: Saturday, March 26, 2011 2:24 AM >> To: Mark Nottingham >> Cc: IETF TOOLS discussion >> Subject: Re: [Tools-discuss] Fwd: [vixie@isc.org: googlebot to the >> rescue] >> >> Hi, >> >> The new draft submission tool doesn't have this problem. > > Just now I used the new submission tool for the first time, and it also > seemed to only need a GET to authorize the actual posting of the I-D. > > -d > > >> I'm about to >> start merging that code to the trunk of the datatracker svn repository >> in something like 10 minutes from now, and do the first deployment >> today. >> >> >> Best, >> >> Henrik >> >> >> >> On 2011-03-23 00:25 Mark Nottingham said the following: >>> In case this hasn't been seen -- it needs to be fixed (i.e., a GET >> shouldn't have such side effects). >>> >>> Cheers, >>> >>> >>> Begin forwarded message: >>> >>>> *Resent-From: *ietf-http-wg@w3.org >>>> *From: *Stephane Bortzmeyer > > >>>> *Date: *23 March 2011 12:01:23 AM AEDT >>>> *To: *HTTP Working Group > wg@w3.org>> >>>> *Subject: **[vixie@isc.org: googlebot to the rescue]* >>>> *organization: *NIC France >>>> *archived-at: * >>>> >>>> The draft management tool apparently can change the state of a draft >>>> in response to a simple GET... >>>> >>>> Nice violation of the HTTP standard :-) >>>> >>>> *From: *Paul Vixie > >>>> *Date: *19 March 2011 2:50:30 AM AEDT >>>> *To: *dnsext@ietf.org >>>> *Subject: **googlebot to the rescue* >>>> >>>> >>>> i think the 0x20 draft was going nowhere in any case so cancelling >> it is fine. >>>> >>>> 148.68.249.66.in-addr.arpa domain name pointer >>>> crawl-66-249-68-148.googlebot.com > 148.googlebot.com>. >>>> >>>> crawl-66-249-68-148.googlebot.com > 148.googlebot.com> has address 66.249.68.148 >>>> >>>> it's interesting that it can be done by a web crawler, though. >>>> >>>> re: >>>> >>>> >>>> *From: *IETF I-D Submission Tool > > >>>> *Date: *18 March 2011 10:36:25 PM AEDT >>>> *To: *ipr@ietf.org , dagon@cc.gatech.edu >> , vixie@isc.org >>>> *Subject: **Submission of draft-vixie-dnsext-dns0x20-00 has been >> Cancelled * >>>> >>>> >>>> This message is to notify you that submission of an Internet-Draft, >> draft-vixie-dnsext-dns0x20-00, has just been cancelled by a user whose >> computer has an IP address of 66.249.68.148. >>>> >>>> The IETF Secretariat. >>>> >>>> >>>> >>>> _______________________________________________ >>>> dnsext mailing list >>>> dnsext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsext >>>> >>>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Tools-discuss mailing list >>> Tools-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/tools-discuss >> _______________________________________________ >> Tools-discuss mailing list >> Tools-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/tools-discuss > > From evnikita2@gmail.com Tue Apr 26 08:04:26 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1D2E0757 for ; Tue, 26 Apr 2011 08:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RMImCP51z7d for ; Tue, 26 Apr 2011 08:04:25 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86B3BE0681 for ; Tue, 26 Apr 2011 08:04:25 -0700 (PDT) Received: by fxm15 with SMTP id 15so582488fxm.31 for ; Tue, 26 Apr 2011 08:04:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xAsL/9jQyy2UhjejSOee0/ugL4vOCQ44Tg8dQrMGKqM=; b=qpJCM6OGs33e/59MMIaDVOO+i1F4f3Y7JGlXcaQqtDbpjTf60HXF4LeA0GidFBvrsw ywOfVvhFPJ2Zgw0yCj+3rUi3QYwRL7X+BMBADQRammlPfb/Y5J8oC98RzdE+gcdH8wOB 1s2R427kehE9eFp27DP2duYp10FPtltha0b7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=GQ0oR5CPbQ6kqHRtr2WbXVXd6jbfvXMzKJJVvzdceRFdIzuF2KevyKYuhzzDT7PUJq TqdFloSvPv4DmXnJ6Tbeb4qmH9JgiYhZ5TQ4s6UEDCeaacw7RxNeHbiAgcsjeYeRy4xV nyrTismvE7XMZF0/V92NL4sFSfQ0jxdGX29gU= Received: by 10.223.17.140 with SMTP id s12mr115743faa.49.1303829966364; Tue, 26 Apr 2011 07:59:26 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id j12sm2030208fax.9.2011.04.26.07.59.24 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 07:59:25 -0700 (PDT) Message-ID: <4DB6DDF9.1060105@gmail.com> Date: Tue, 26 Apr 2011 18:00:09 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <4DB59F62.9000701@gmail.com> <198D2050-3684-4087-B49B-4AC3DBD183B7@frobbit.se> In-Reply-To: <198D2050-3684-4087-B49B-4AC3DBD183B7@frobbit.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 15:04:26 -0000 Hello all, I think all who took time to comment my message are losing my point. I complained about Rfcmarkup tool analyzing the draft's name, not its contents when deciding to put pr not to put some RFC as the previous version of the draft. It is logically useful when some draft obsoletes another RFC when approved, eg. http://tools.ietf.org/html/draft-iesg-rfc1150bis-00 where we have "(RFC 1150) 00" label. The draft I pointed to has no any regulations regarding obsoleting anything; Rfcmarkup, though, added the label of RFC 5892 being the previous version of it. My complaint was about abnormal handling of the draft name/header while finding out Obsoletes/Updates relationships. Mykyta Yevstifeyev From paul.hoffman@vpnc.org Tue Apr 26 08:29:02 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3BFE07ED for ; Tue, 26 Apr 2011 08:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.513 X-Spam-Level: X-Spam-Status: No, score=-101.513 tagged_above=-999 required=5 tests=[AWL=1.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9TcVflujR8b for ; Tue, 26 Apr 2011 08:29:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF34E07BF for ; Tue, 26 Apr 2011 08:29:01 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3QFSvNr052285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Apr 2011 08:28:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DB6DDF9.1060105@gmail.com> Date: Tue, 26 Apr 2011 08:28:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB59F62.9000701@gmail.com> <198D2050-3684-4087-B49B-4AC3DBD183B7@frobbit.se> <4DB6DDF9.1060105@gmail.com> To: Mykyta Yevstifeyev X-Mailer: Apple Mail (2.1084) Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 15:29:02 -0000 On Apr 26, 2011, at 8:00 AM, Mykyta Yevstifeyev wrote: > I complained about Rfcmarkup tool analyzing the draft's name, not its = contents when deciding to put pr not to put some RFC as the previous = version of the draft. It is logically useful when some draft obsoletes = another RFC when approved, eg. = http://tools.ietf.org/html/draft-iesg-rfc1150bis-00 where we have "(RFC = 1150) 00" label. >=20 > The draft I pointed to has no any regulations regarding obsoleting = anything; Rfcmarkup, though, added the label of RFC 5892 being the = previous version of it. My complaint was about abnormal handling of the = draft name/header while finding out Obsoletes/Updates relationships. With all due respect, your first complaint was without any merit. Your = new complaint, that the header listing an RFC as a version of a draft as = being "abnormal", is silly as well. The link there is advisory and for = the benefit of someone reading the current draft. If you don't like that = link, ignore it. --Paul Hoffman From evnikita2@gmail.com Tue Apr 26 10:21:53 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27D9E07A8 for ; Tue, 26 Apr 2011 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsMfL99k6bsA for ; Tue, 26 Apr 2011 10:21:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4C15E07D2 for ; Tue, 26 Apr 2011 10:21:52 -0700 (PDT) Received: by fxm15 with SMTP id 15so694519fxm.31 for ; Tue, 26 Apr 2011 10:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ppXyeQmeJaGWjlYXb2oNh/Tor/19gErBxVc9+1b0aXU=; b=cF+hPJ8F2v/GaMvzmHBWuIkSHD/u671cVhzyfGhH3ChDjUou72gFqAt1oUbEcdd6hJ kp090Eq+7MCg3XHuRQf7CRiBQnyPeQc3V0m2xEDsJUi2IqHtblBx8Gu+yjzDr9NO5ZPq dMUV78gdsAUloUnouN4/I1aHQDWbXnBjIK3R0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=LJub6ISuTxROI0o4NgKYm/uwh1Gq+d2mHLeyvLJr/wN8EpIyte/dmuNHMkPrwQUL+w 1pyQs+BnCDLUilc7Vku7dl7N5VTfX+tAqXBzQHFDmhqSliR71dIN2YQPzN8bOmnRbDN7 QruRIkBiYRQxhfoH9Y1tG+0Mhb/7Hx6hVANGk= Received: by 10.223.73.133 with SMTP id q5mr1141605faj.127.1303838511575; Tue, 26 Apr 2011 10:21:51 -0700 (PDT) Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id 14sm2064150fas.30.2011.04.26.10.21.50 (version=SSLv3 cipher=OTHER); Tue, 26 Apr 2011 10:21:50 -0700 (PDT) Message-ID: <4DB6FF59.4020906@gmail.com> Date: Tue, 26 Apr 2011 20:22:33 +0300 From: Mykyta Yevstifeyev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Hoffman References: <4DB59F62.9000701@gmail.com> <198D2050-3684-4087-B49B-4AC3DBD183B7@frobbit.se> <4DB6DDF9.1060105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] http://tools.ietf.org/html/draft-faltstrom-5892bis-04 HTML page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 17:21:54 -0000 26.04.2011 18:28, Paul Hoffman wrote: > On Apr 26, 2011, at 8:00 AM, Mykyta Yevstifeyev wrote: > Since there is nobody who managed to understand my complaint and it is very unlikely somebody who would understand it will appear, I see there is no sense in continuing this discussion. I won't insist on any actions regarding it, even though I do not renounce my complaint. Mykyta Yevstifeyev >> I complained about Rfcmarkup tool analyzing the draft's name, not its contents when deciding to put pr not to put some RFC as the previous version of the draft. It is logically useful when some draft obsoletes another RFC when approved, eg. http://tools.ietf.org/html/draft-iesg-rfc1150bis-00 where we have "(RFC 1150) 00" label. >> >> The draft I pointed to has no any regulations regarding obsoleting anything; Rfcmarkup, though, added the label of RFC 5892 being the previous version of it. My complaint was about abnormal handling of the draft name/header while finding out Obsoletes/Updates relationships. > With all due respect, your first complaint was without any merit. Your new complaint, that the header listing an RFC as a version of a draft as being "abnormal", is silly as well. The link there is advisory and for the benefit of someone reading the current draft. If you don't like that link, ignore it. > > --Paul Hoffman > > From ietfdbh@comcast.net Thu Apr 28 09:40:46 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24FDEE06D2 for ; Thu, 28 Apr 2011 09:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2-5XK7-GQBC for ; Thu, 28 Apr 2011 09:40:45 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 86299E0698 for ; Thu, 28 Apr 2011 09:40:45 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta01.westchester.pa.mail.comcast.net with comcast id d3z61g0071ei1Bg514glwf; Thu, 28 Apr 2011 16:40:45 +0000 Received: from davidPC ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id d4gk1g00a2JQnJT3k4gkpN; Thu, 28 Apr 2011 16:40:45 +0000 From: "David Harrington" To: Date: Thu, 28 Apr 2011 12:40:35 -0400 Message-ID: <1B319C0B03B24079A1FA152C36A6FF2D@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16776 Thread-Index: AcwFwv8+6V5gfV4uSPeLcUIp/9BBiA== Subject: [Tools-discuss] RFC search engine X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 16:40:46 -0000 Hi, What is the best way to search for all BCPs in the datatracker? The old RFC search allowed you to request BCP, STD, and FYI as well as RFC. Is there a way to display the keywords associated with search results? Is there a way to update the keywords for a document? (e.g., add a keyword) David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) From ahagens@amsl.com Thu Apr 28 16:27:24 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D073FE0733 for ; Thu, 28 Apr 2011 16:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHYQnyT+Yrny for ; Thu, 28 Apr 2011 16:27:24 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [64.170.98.20]) by ietfa.amsl.com (Postfix) with ESMTP id 481B7E06EC for ; Thu, 28 Apr 2011 16:27:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c1a.amsl.com (Postfix) with ESMTP id 448D3E08CE; Thu, 28 Apr 2011 16:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c1a.amsl.com ([127.0.0.1]) by localhost (c1a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mPQQVzf1U2R; Thu, 28 Apr 2011 16:27:24 -0700 (PDT) Received: from [64.170.98.172] (unknown [64.170.98.172]) by c1a.amsl.com (Postfix) with ESMTPSA id 2978BE07B0; Thu, 28 Apr 2011 16:27:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Alice Hagens In-Reply-To: <1B319C0B03B24079A1FA152C36A6FF2D@davidPC> Date: Thu, 28 Apr 2011 16:27:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B319C0B03B24079A1FA152C36A6FF2D@davidPC> To: "David Harrington" X-Mailer: Apple Mail (2.1084) Cc: Tools Team Discussion , RFC Editor Subject: Re: [Tools-discuss] RFC search engine X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 23:27:24 -0000 David, Although you are asking about the datatracker, from = http://www.rfc-editor.org/rfcsearch.html you can search as follows. On = the right, select Search: BCP and Show Keywords: On. Enter text in the = search box, such as simply the character "." (as it does not allow empty = search). This yields a list of 159 RFCs and their keywords. = Additionally, lists of RFCs by status are available from = http://www.rfc-editor.org/category.html. The RFC Editor maintains the keywords for RFCs. Updates should be sent = to rfc-editor@rfc-editor.org. Thank you. Alice for the RFC Production Center On Apr 28, 2011, at 9:40 AM, David Harrington wrote: > Hi, >=20 > What is the best way to search for all BCPs in the datatracker? > The old RFC search allowed you to request BCP, STD, and FYI as well as > RFC. >=20 > Is there a way to display the keywords associated with search results? > Is there a way to update the keywords for a document? (e.g., add a > keyword) >=20 > David Harrington > Director, IETF Transport Area > ietfdbh@comcast.net (preferred for ietf) > dbharrington@huaweisymantec.com > +1 603 828 1401 (cell) >=20 > _______________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 From fred@cisco.com Thu Apr 28 13:54:17 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0644BE071E for ; Thu, 28 Apr 2011 13:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iej1rbLF+yx0 for ; Thu, 28 Apr 2011 13:54:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id E8896E0670 for ; Thu, 28 Apr 2011 13:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=638615; q=dns/txt; s=iport; t=1304024054; x=1305233654; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=zkju/C+fujoYOxppl6qcM2UoUEAluDg5d0KFUgbbB70=; b=f2fPaEhZgGtst1tYdwaXactjZww3nXs/GsiMDG1xLiInlfuXQaK2A0kl 8RdgHIZeH7Msyadj3zQV3AKJqMBZOMlyA3hUXBHEHEGKfgzKLGm0kctJu kTZ7IPx3M3a5f9QR0rFPknKK1K287LPXdifoyoRZ+xD6f1LalX/C7sVtk E=; X-Files: best-current-practice.txt, bcps-in-numeric-order.txt, multihoming-search.txt : 38349, 38349, 543136 X-IronPort-AV: E=Sophos;i="4.64,282,1301875200"; d="txt'?scan'208";a="438445623" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 28 Apr 2011 20:54:14 +0000 Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3SKrnvT016591; Thu, 28 Apr 2011 20:53:53 GMT Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Thu, 28 Apr 2011 13:53:53 -0700 X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Thu, 28 Apr 2011 13:53:53 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <1B319C0B03B24079A1FA152C36A6FF2D@davidPC> Date: Thu, 28 Apr 2011 13:53:35 -0700 Message-Id: <3E4B2789-F5AC-4E9E-BEE7-BA36C9DEB481@cisco.com> References: <1B319C0B03B24079A1FA152C36A6FF2D@davidPC> To: David Harrington X-Mailer: Apple Mail (2.1084) Content-Type: multipart/mixed; boundary=Apple-Mail-93--700698807 X-Mailman-Approved-At: Fri, 29 Apr 2011 01:59:35 -0700 Cc: tools-discuss@ietf.org Subject: Re: [Tools-discuss] RFC search engine X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 20:54:17 -0000 --Apple-Mail-93--700698807 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 28, 2011, at 9:40 AM, David Harrington wrote: > What is the best way to search for all BCPs in the datatracker? > The old RFC search allowed you to request BCP, STD, and FYI as well as > RFC. >=20 > Is there a way to display the keywords associated with search results? > Is there a way to update the keywords for a document? (e.g., add a > keyword) I have built myself a few ad hoc tools that build on an internet draft = or RFC mirror I keep on my laptop, but to be honest I'm not happy with = them. I do a lot of old-fashioned grepping. I have attached some files. You may find the data useful. Or not. :-) I'm giving you two versions. I have built myself a few ad hoc tools that = build on an internet draft or RFC mirror I keep on my laptop, but to be = honest I'm not happy with them. I do a lot of old-fashioned grepping. I = frequently use a hack tool I wrote for myself (which I call get-refs). = It is essentially a limited version of grep that will look through a = text file for paragraphs (not lines) that *do* contain one or more of a = set of character strings and *do not* contain any of another set of = character strings. The character strings may contain white space, which = includes spanning lines. Hence, it can look not only for words but = phrases. As with any unix filter, it can be used in tandem through a = pipe for certain purposes. I find it useful, but if I were to commission = a proper tool I wouldn't do it this way (I would probably want some form = of database query). My point here is partly to give you some data that = may be useful to your question, and to give some discussion of tools = that may give you and Henrik some ideas on questions I find myself = asking and therefore possible use cases for the tool. One thing that I = would change if I could easily think of a way to do it would be to be = able to look for this *and* that - "contains '(status: best current = practice)' *and* 'Nominations Committee', but neither 'obsoleted' nor = 'historic'". The attached "best-current-practice.txt" file is the result of rfc '(status: best current practice)'=20 which devolves to=20 get-refs ~/rfc/rfc-index.txt -obsoleted -historic '(status: best = current practice)'=20 In other words, it scans rfc-index.txt for paragraphs that contain = '(status: best current practice)' and do not contain either 'historic' = or 'obsoleted' and writes them to stdout. It also concocts a URL for the = file, which I find useful primarily when I'm telling someone else about = the result.=20 I have a similar tool for internet drafts, with the exception that it = scans a list of current internet draft versions for the text I give it = and then gives me the corresponding text from 1id-index.txt along with a = URL. If I ask it about 6to4, for example, I find that there are four = current internet drafts that have the character string in their moniker: http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-advisory http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory "Advisory Guidelines for 6to4 Deployment", Brian Carpenter, 26-Apr-11, http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status", Ole Troan, 27-Apr-11, = http://datatracker.ietf.org/doc/draft-kuarsingh-v6ops-6to4-provider-manage= d-tunnel = http://tools.ietf.org/html/draft-kuarsingh-v6ops-6to4-provider-managed-tun= nel "6to4 Provider Managed Tunnels", Victor Kuarsingh, Yiu Lee, Olivier Vautrin, 13-Mar-11, http://datatracker.ietf.org/doc/draft-troan-v6ops-6to4-to-historic http://tools.ietf.org/html/draft-troan-v6ops-6to4-to-historic "Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status", Ole Troan, 9-Mar-11, The "bcps in numeric order" is the result of a similar search, but this = time in a command-line script. What I notices was that I had 162 = documents listed as BCPs, but the highest BCP number was=20 > foreach i (00 01 02 03 04 05 06 07 08 09 `count 10 99`) > foreach? rfc bcp00$i >> bcps-in-numeric-order.txt > foreach? end > foreach i (`count 100 200`) > foreach? rfc bcp0$i >> bcps-in-numeric-order.txt > foreach? end and gives you (surprise) the BCPs in numeric order. I got curious about = the fact that we have more documents classified as BCPs than we have BCP = numbers. It turns out that we have some documents that update BCPs, and = they have the same BCP number as the things they update. We also have = some BCP numbers that are unused, at least in the rfc-index.txt file - = there is no BCP0001 or BCP0002, and a couple of others. --Apple-Mail-93--700698807 Content-Disposition: attachment; filename=best-current-practice.txt Content-Type: text/plain; name="best-current-practice.txt" Content-Transfer-Encoding: 7bit http://www.ietf.org/rfc/rfc1915.txt 1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol. F. Kastenholz. February 1996. (Format: TXT=14347 bytes) (Also BCP0003) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc1917.txt 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA. P. Nesser II. February 1996. (Format: TXT=23623 bytes) (Also BCP0004) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc1918.txt 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc1930.txt 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS). J. Hawkinson, T. Bates. March 1996. (Format: TXT=22073 bytes) (Also BCP0006) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2008.txt 2008 Implications of Various Address Allocation Policies for Internet Routing. Y. Rekhter, T. Li. October 1996. (Format: TXT=34717 bytes) (Also BCP0007) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2014.txt 2014 IRTF Research Group Guidelines and Procedures. A. Weinrib, J. Postel. October 1996. (Format: TXT=27507 bytes) (Also BCP0008) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2026.txt 2026 The Internet Standards Process -- Revision 3. S. Bradner. October 1996. (Format: TXT=86731 bytes) (Obsoletes RFC1602, RFC1871) (Updated by RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC5657, RFC5742) (Also BCP0009) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2028.txt 2028 The Organizations Involved in the IETF Standards Process. R. Hovey, S. Bradner. October 1996. (Format: TXT=13865 bytes) (Updated by RFC3668, RFC3979) (Also BCP0011) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2050.txt 2050 Internet Registry IP Allocation Guidelines. K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format: TXT=28975 bytes) (Obsoletes RFC1466) (Also BCP0012) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2119.txt 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. (Format: TXT=4723 bytes) (Also BCP0014) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2148.txt 2148 Deployment of the Internet White Pages Service. H. Alvestrand, P. Jurg. September 1997. (Format: TXT=31539 bytes) (Also BCP0015) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2182.txt 2182 Selection and Operation of Secondary DNS Servers. R. Elz, R. Bush, S. Bradner, M. Patton. July 1997. (Format: TXT=27456 bytes) (Also BCP0016) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2219.txt 2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2277.txt 2277 IETF Policy on Character Sets and Languages. H. Alvestrand. January 1998. (Format: TXT=16622 bytes) (Also BCP0018) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2317.txt 2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P. Vixie. March 1998. (Format: TXT=17744 bytes) (Also BCP0020) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2350.txt 2350 Expectations for Computer Security Incident Response. N. Brownlee, E. Guttman. June 1998. (Format: TXT=86545 bytes) (Also BCP0021) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2360.txt 2360 Guide for Internet Standards Writers. G. Scott. June 1998. (Format: TXT=47280 bytes) (Also BCP0022) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2365.txt 2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. (Format: TXT=17770 bytes) (Also BCP0023) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2379.txt 2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. (Format: TXT=15174 bytes) (Also BCP0024) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2418.txt 2418 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998. (Format: TXT=62857 bytes) (Obsoletes RFC1603) (Updated by RFC3934) (Also BCP0025) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2438.txt 2438 Advancement of MIB specifications on the IETF Standards Track. M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998. (Format: TXT=13633 bytes) (Also BCP0027) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2488.txt 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms. M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT=47857 bytes) (Also BCP0028) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2505.txt 2505 Anti-Spam Recommendations for SMTP MTAs. G. Lindberg. February 1999. (Format: TXT=53597 bytes) (Also BCP0030) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2506.txt 2506 Media Feature Tag Registration Procedure. K. Holtman, A. Mutz, T. Hardie. March 1999. (Format: TXT=24892 bytes) (Also BCP0031) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2606.txt 2606 Reserved Top Level DNS Names. D. Eastlake 3rd, A. Panitz. June 1999. (Format: TXT=8008 bytes) (Also BCP0032) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2644.txt 2644 Changing the Default for Directed Broadcasts in Routers. D. Senie. August 1999. (Format: TXT=6820 bytes) (Updates RFC1812) (Also BCP0034) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2736.txt 2736 Guidelines for Writers of RTP Payload Format Specifications. M. Handley, C. Perkins. December 1999. (Format: TXT=24143 bytes) (Also BCP0036) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2780.txt 2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000. (Format: TXT=18954 bytes) (Updated by RFC4443, RFC5237, RFC5771) (Also BCP0037) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2827.txt 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2850.txt 2850 Charter of the Internet Architecture Board (IAB). Internet Architecture Board, B. Carpenter, Ed.. May 2000. (Format: TXT=15984 bytes) (Obsoletes RFC1601) (Also BCP0039) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2870.txt 2870 Root Name Server Operational Requirements. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. June 2000. (Format: TXT=21133 bytes) (Obsoletes RFC2010) (Also BCP0040) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2914.txt 2914 Congestion Control Principles. S. Floyd. September 2000. (Format: TXT=43823 bytes) (Also BCP0041) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2939.txt 2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types. R. Droms. September 2000. (Format: TXT=13631 bytes) (Obsoletes RFC2489) (Also BCP0043) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2964.txt 2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT=18899 bytes) (Also BCP0044) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2978.txt 2978 IANA Charset Registration Procedures. N. Freed, J. Postel. October 2000. (Format: TXT=21615 bytes) (Obsoletes RFC2278) (Also BCP0019) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3005.txt 3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: TXT=5682 bytes) (Also BCP0045) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3013.txt 3013 Recommended Internet Service Provider Security Services and Procedures. T. Killalea. November 2000. (Format: TXT=27905 bytes) (Also BCP0046) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3150.txt 3150 End-to-end Performance Implications of Slow Links. S. Dawkins, G. Montenegro, M. Kojo, V. Magret. July 2001. (Format: TXT=39942 bytes) (Also BCP0048) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3155.txt 3155 End-to-end Performance Implications of Links with Errors. S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya. August 2001. (Format: TXT=36388 bytes) (Also BCP0050) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3172.txt 3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa"). G. Huston, Ed.. September 2001. (Format: TXT=18097 bytes) (Also BCP0052) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3180.txt 3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001. (Format: TXT=8225 bytes) (Obsoletes RFC2770) (Also BCP0053) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3184.txt 3184 IETF Guidelines for Conduct. S. Harris. October 2001. (Format: TXT=7413 bytes) (Also BCP0054) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3205.txt 3205 On the use of HTTP as a Substrate. K. Moore. February 2002. (Format: TXT=34785 bytes) (Also BCP0056) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3227.txt 3227 Guidelines for Evidence Collection and Archiving. D. Brezinski, T. Killalea. February 2002. (Format: TXT=18468 bytes) (Also BCP0055) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3228.txt 3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP). B. Fenner. February 2002. (Format: TXT=6473 bytes) (Also BCP0057) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3233.txt 3233 Defining the IETF. P. Hoffman, S. Bradner. February 2002. (Format: TXT=6401 bytes) (Also BCP0058) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3349.txt 3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force. M. Rose. July 2002. (Format: TXT=7916 bytes) (Also BCP0059) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3360.txt 3360 Inappropriate TCP Resets Considered Harmful. S. Floyd. August 2002. (Format: TXT=46748 bytes) (Also BCP0060) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3365.txt 3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols. J. Schiller. August 2002. (Format: TXT=16411 bytes) (Also BCP0061) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3366.txt 3366 Advice to link designers on link Automatic Repeat reQuest (ARQ). G. Fairhurst, L. Wood. August 2002. (Format: TXT=66097 bytes) (Also BCP0062) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3372.txt 3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures. A. Vemuri, J. Peterson. September 2002. (Format: TXT=49893 bytes) (Also BCP0063) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3405.txt 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures. M. Mealling. October 2002. (Format: TXT=19469 bytes) (Also BCP0065) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3406.txt 3406 Uniform Resource Names (URN) Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. October 2002. (Format: TXT=43707 bytes) (Obsoletes RFC2611) (Also BCP0066) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3438.txt 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update. W. Townsley. December 2002. (Format: TXT=9135 bytes) (Also BCP0068) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3449.txt 3449 TCP Performance Implications of Network Path Asymmetry. H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. December 2002. (Format: TXT=108839 bytes) (Also BCP0069) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3470.txt 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols. S. Hollenbeck, M. Rose, L. Masinter. January 2003. (Format: TXT=64252 bytes) (Also BCP0070) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3481.txt 3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks. H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov. February 2003. (Format: TXT=61528 bytes) (Also BCP0071) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3552.txt 3552 Guidelines for Writing RFC Text on Security Considerations. E. Rescorla, B. Korver. July 2003. (Format: TXT=110393 bytes) (Also BCP0072) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3553.txt 3553 An IETF URN Sub-namespace for Registered Protocol Parameters. M. Mealling, L. Masinter, T. Hardie, G. Klyne. June 2003. (Format: TXT=14815 bytes) (Also BCP0073) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3584.txt 3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. August 2003. (Format: TXT=115222 bytes) (Obsoletes RFC2576) (Also BCP0074) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3665.txt 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT=163159 bytes) (Also BCP0075) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3666.txt 3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT=200478 bytes) (Also BCP0076) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3677.txt 3677 IETF ISOC Board of Trustee Appointment Procedures. L. Daigle, Ed., Internet Architecture Board. December 2003. (Format: TXT=13008 bytes) (Also BCP0077) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3681.txt 3681 Delegation of E.F.F.3.IP6.ARPA. R. Bush, R. Fink. January 2004. (Format: TXT=7137 bytes) (Also BCP0080) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3683.txt 3683 A Practice for Revoking Posting Rights to IETF Mailing Lists. M. Rose. March 2004. (Format: TXT=15698 bytes) (Also BCP0083) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3688.txt 3688 The IETF XML Registry. M. Mealling. January 2004. (Format: TXT=17325 bytes) (Also BCP0081) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3692.txt 3692 Assigning Experimental and Testing Numbers Considered Useful. T. Narten. January 2004. (Format: TXT=15054 bytes) (Updates RFC2434) (Also BCP0082) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3704.txt 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also BCP0084) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3725.txt 3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP). J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo. April 2004. (Format: TXT=77308 bytes) (Also BCP0085) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3766.txt 3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys. H. Orman, P. Hoffman. April 2004. (Format: TXT=55939 bytes) (Also BCP0086) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3777.txt 3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin, Ed.. June 2004. (Format: TXT=76395 bytes) (Obsoletes RFC2727) (Updated by RFC5078, RFC5633, RFC5680) (Also BCP0010) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3785.txt 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric. F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp. May 2004. (Format: TXT=17475 bytes) (Also BCP0087) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3818.txt 3818 IANA Considerations for the Point-to-Point Protocol (PPP). V. Schryver. June 2004. (Format: TXT=6321 bytes) (Also BCP0088) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3819.txt 3819 Advice for Internet Subnetwork Designers. P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. July 2004. (Format: TXT=152174 bytes) (Also BCP0089) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3864.txt 3864 Registration Procedures for Message Header Fields. G. Klyne, M. Nottingham, J. Mogul. September 2004. (Format: TXT=36231 bytes) (Also BCP0090) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3901.txt 3901 DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT=10025 bytes) (Also BCP0091) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3933.txt 3933 A Model for IETF Process Experiments. J. Klensin, S. Dawkins. November 2004. (Format: TXT=14409 bytes) (Also BCP0093) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3934.txt 3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists. M. Wasserman. October 2004. (Format: TXT=8488 bytes) (Updates RFC2418) (Also BCP0094) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3935.txt 3935 A Mission Statement for the IETF. H. Alvestrand. October 2004. (Format: TXT=16639 bytes) (Also BCP0095) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3936.txt 3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP). K. Kompella, J. Lang. October 2004. (Format: TXT=15314 bytes) (Updates RFC3209, RFC2205) (Also BCP0096) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3967.txt 3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level. R. Bush, T. Narten. December 2004. (Format: TXT=12251 bytes) (Updated by RFC4897) (Also BCP0097) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3968.txt 3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT=20615 bytes) (Updates RFC3427) (Also BCP0098) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3969.txt 3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT=12119 bytes) (Updates RFC3427) (Updated by RFC5727) (Also BCP0099) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3979.txt 3979 Intellectual Property Rights in IETF Technology. S. Bradner, Ed.. March 2005. (Format: TXT=41366 bytes) (Obsoletes RFC3668) (Updates RFC2026, RFC2028) (Updated by RFC4879) (Also BCP0079) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4020.txt 4020 Early IANA Allocation of Standards Track Code Points. K. Kompella, A. Zinin. February 2005. (Format: TXT=13706 bytes) (Also BCP0100) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4052.txt 4052 IAB Processes for Management of IETF Liaison Relationships. L. Daigle, Ed., Internet Architecture Board. April 2005. (Format: TXT=18360 bytes) (Also BCP0102) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4053.txt 4053 Procedures for Handling Liaison Statements to and from the IETF. S. Trowbridge, S. Bradner, F. Baker. April 2005. (Format: TXT=38816 bytes) (Also BCP0103) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4071.txt 4071 Structure of the IETF Administrative Support Activity (IASA). R. Austein, Ed., B. Wijnen, Ed.. April 2005. (Format: TXT=48614 bytes) (Updated by RFC4371) (Also BCP0101) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4084.txt 4084 Terminology for Describing Internet Connectivity. J. Klensin. May 2005. (Format: TXT=24522 bytes) (Also BCP0104) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4085.txt 4085 Embedding Globally-Routable Internet Addresses Considered Harmful. D. Plonka. June 2005. (Format: TXT=22656 bytes) (Also BCP0105) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4086.txt 4086 Randomness Requirements for Security. D. Eastlake 3rd, J. Schiller, S. Crocker. June 2005. (Format: TXT=114321 bytes) (Obsoletes RFC1750) (Also BCP0106) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4107.txt 4107 Guidelines for Cryptographic Key Management. S. Bellovin, R. Housley. June 2005. (Format: TXT=14752 bytes) (Also BCP0107) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4159.txt 4159 Deprecation of "ip6.int". G. Huston. August 2005. (Format: TXT=5353 bytes) (Also BCP0109) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4170.txt 4170 Tunneling Multiplexed Compressed RTP (TCRTP). B. Thompson, T. Koren, D. Wing. November 2005. (Format: TXT=48990 bytes) (Also BCP0110) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4181.txt 4181 Guidelines for Authors and Reviewers of MIB Documents. C. Heard, Ed.. September 2005. (Format: TXT=102521 bytes) (Updated by RFC4841) (Also BCP0111) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4222.txt 4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance. G. Choudhury, Ed.. October 2005. (Format: TXT=34132 bytes) (Also BCP0112) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4288.txt 4288 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT=52667 bytes) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4289.txt 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT=21502 bytes) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4333.txt 4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process. G. Huston, Ed., B. Wijnen, Ed.. December 2005. (Format: TXT=15396 bytes) (Also BCP0113) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4371.txt 4371 BCP 101 Update for IPR Trust. B. Carpenter, Ed., L. Lynch, Ed.. January 2006. (Format: TXT=6901 bytes) (Updates RFC4071) (Also BCP0101) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4384.txt 4384 BGP Communities for Data Collection. D. Meyer. February 2006. (Format: TXT=26078 bytes) (Also BCP0114) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4395.txt 4395 Guidelines and Registration Procedures for New URI Schemes. T. Hansen, T. Hardie, L. Masinter. February 2006. (Format: TXT=31933 bytes) (Obsoletes RFC2717, RFC2718) (Also BCP0035) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4446.txt 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3). L. Martini. April 2006. (Format: TXT=19782 bytes) (Also BCP0116) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4497.txt 4497 Interworking between the Session Initiation Protocol (SIP) and QSIG. J. Elwell, F. Derks, P. Mourot, O. Rousseau. May 2006. (Format: TXT=149992 bytes) (Also BCP0117) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4520.txt 4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. June 2006. (Format: TXT=34298 bytes) (Obsoletes RFC3383) (Also BCP0064) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4521.txt 4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions. K. Zeilenga. June 2006. (Format: TXT=34585 bytes) (Also BCP0118) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4579.txt 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents. A. Johnston, O. Levin. August 2006. (Format: TXT=96506 bytes) (Also BCP0119) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4608.txt 4608 Source-Specific Protocol Independent Multicast in 232/8. D. Meyer, R. Rockell, G. Shepherd. August 2006. (Format: TXT=15030 bytes) (Also BCP0120) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4611.txt 4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios. M. McBride, J. Meylor, D. Meyer. August 2006. (Format: TXT=33230 bytes) (Also BCP0121) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4632.txt 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT=66944 bytes) (Obsoletes RFC1519) (Also BCP0122) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4647.txt 4647 Matching of Language Tags. A. Phillips, M. Davis. September 2006. (Format: TXT=45595 bytes) (Obsoletes RFC3066) (Also BCP0047) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4697.txt 4697 Observed DNS Resolution Misbehavior. M. Larson, P. Barber. October 2006. (Format: TXT=45187 bytes) (Also BCP0123) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4774.txt 4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field. S. Floyd. November 2006. (Format: TXT=37144 bytes) (Updated by RFC6040) (Also BCP0124) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4775.txt 4775 Procedures for Protocol Extensions and Variations. S. Bradner, B. Carpenter, Ed., T. Narten. December 2006. (Format: TXT=32797 bytes) (Also BCP0125) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4786.txt 4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT=56818 bytes) (Also BCP0126) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4787.txt 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. F. Audet, Ed., C. Jennings. January 2007. (Format: TXT=68693 bytes) (Also BCP0127) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4841.txt 4841 RFC 4181 Update to Recognize the IETF Trust. C. Heard, Ed.. March 2007. (Format: TXT=4414 bytes) (Updates RFC4181) (Also BCP0111) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4879.txt 4879 Clarification of the Third Party Disclosure Procedure in RFC 3979. T. Narten. April 2007. (Format: TXT=5570 bytes) (Updates RFC3979) (Also BCP0079) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4897.txt 4897 Handling Normative References to Standards-Track Documents. J. Klensin, S. Hartman. June 2007. (Format: TXT=13023 bytes) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4928.txt 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks. G. Swallow, S. Bryant, L. Andersson. June 2007. (Format: TXT=18376 bytes) (Also BCP0128) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4929.txt 4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures. L. Andersson, Ed., A. Farrel, Ed.. June 2007. (Format: TXT=56742 bytes) (Also BCP0129) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4940.txt 4940 IANA Considerations for OSPF. K. Kompella, B. Fenner. July 2007. (Format: TXT=27595 bytes) (Also BCP0130) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4961.txt 4961 Symmetric RTP / RTP Control Protocol (RTCP). D. Wing. July 2007. (Format: TXT=12539 bytes) (Also BCP0131) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4962.txt 4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management. R. Housley, B. Aboba. July 2007. (Format: TXT=54927 bytes) (Also BCP0132) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5033.txt 5033 Specifying New Congestion Control Algorithms. S. Floyd, M. Allman. August 2007. (Format: TXT=23469 bytes) (Also BCP0133) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5068.txt 5068 Email Submission Operations: Access and Accountability Requirements. C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. November 2007. (Format: TXT=24481 bytes) (Also BCP0134) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5135.txt 5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT). D. Wing, T. Eckert. February 2008. (Format: TXT=36528 bytes) (Also BCP0135) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5137.txt 5137 ASCII Escaping of Unicode Characters. J. Klensin. February 2008. (Format: TXT=27742 bytes) (Also BCP0137) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5226.txt 5226 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. May 2008. (Format: TXT=66160 bytes) (Obsoletes RFC2434) (Also BCP0026) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5237.txt 5237 IANA Allocation Guidelines for the Protocol Field. J. Arkko, S. Bradner. February 2008. (Format: TXT=9303 bytes) (Updates RFC2780) (Also BCP0037) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5248.txt 5248 A Registry for SMTP Enhanced Mail System Status Codes. T. Hansen, J. Klensin. June 2008. (Format: TXT=23845 bytes) (Updates RFC3463, RFC4468, RFC4954) (Also BCP0138) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5249.txt 5249 Templates for Internet-Drafts Containing MIB Modules. D. Harrington, Ed.. July 2008. (Format: TXT=7362 bytes) (Also BCP0139) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5266.txt 5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE). V. Devarapalli, P. Eronen. June 2008. (Format: TXT=33186 bytes) (Also BCP0136) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5342.txt 5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters. D. Eastlake 3rd. September 2008. (Format: TXT=42800 bytes) (Updates RFC2153) (Also BCP0141) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5358.txt 5358 Preventing Use of Recursive Nameservers in Reflector Attacks. J. Damas, F. Neves. October 2008. (Format: TXT=14957 bytes) (Also BCP0140) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5359.txt 5359 Session Initiation Protocol Service Examples. A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. October 2008. (Format: TXT=289446 bytes) (Also BCP0144) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5378.txt 5378 Rights Contributors Provide to the IETF Trust. S. Bradner, Ed., J. Contreras, Ed.. November 2008. (Format: TXT=37980 bytes) (Obsoletes RFC3978, RFC4748) (Updates RFC2026) (Also BCP0078) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5382.txt 5382 NAT Behavioral Requirements for TCP. S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. October 2008. (Format: TXT=50306 bytes) (Also BCP0142) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5383.txt 5383 Deployment Considerations for Lemonade-Compliant Mobile Email. R. Gellens. October 2008. (Format: TXT=28290 bytes) (Also BCP0143) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5405.txt 5405 Unicast UDP Usage Guidelines for Application Designers. L. Eggert, G. Fairhurst. November 2008. (Format: TXT=69607 bytes) (Also BCP0145) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5406.txt 5406 Guidelines for Specifying the Use of IPsec Version 2. S. Bellovin. February 2009. (Format: TXT=30393 bytes) (Also BCP0146) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5407.txt 5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP). M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat. December 2008. (Format: TXT=120005 bytes) (Also BCP0147) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5508.txt 5508 NAT Behavioral Requirements for ICMP. P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. April 2009. (Format: TXT=67985 bytes) (Also BCP0148) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5589.txt 5589 Session Initiation Protocol (SIP) Call Control - Transfer. R. Sparks, A. Johnston, Ed., D. Petrie. June 2009. (Format: TXT=119434 bytes) (Also BCP0149) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5597.txt 5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol. R. Denis-Courmont. September 2009. (Format: TXT=18933 bytes) (Also BCP0150) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5615.txt 5615 H.248/MEGACO Registration Procedures. C. Groves, Y. Lin. August 2009. (Format: TXT=29069 bytes) (Also BCP0151) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5625.txt 5625 DNS Proxy Implementation Guidelines. R. Bellis. August 2009. (Format: TXT=24585 bytes) (Also BCP0152) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5633.txt 5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers. S. Dawkins, Ed.. August 2009. (Format: TXT=11117 bytes) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5646.txt 5646 Tags for Identifying Languages. A. Phillips, Ed., M. Davis, Ed.. September 2009. (Format: TXT=208592 bytes) (Obsoletes RFC4646) (Also BCP0047) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5657.txt 5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard. L. Dusseault, R. Sparks. September 2009. (Format: TXT=29327 bytes) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5680.txt 5680 The Nominating Committee Process: Open Disclosure of Willing Nominees. S. Dawkins, Ed.. October 2009. (Format: TXT=14296 bytes) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5727.txt 5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area. J. Peterson, C. Jennings, R. Sparks. March 2010. (Format: TXT=35033 bytes) (Obsoletes RFC3427) (Updates RFC3265, RFC3969) (Also BCP0067) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5735.txt 5735 Special Use IPv4 Addresses. M. Cotton, L. Vegoda. January 2010. (Format: TXT=20369 bytes) (Obsoletes RFC3330) (Also BCP0153) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5742.txt 5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions. H. Alvestrand, R. Housley. December 2009. (Format: TXT=21067 bytes) (Obsoletes RFC3932) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5771.txt 5771 IANA Guidelines for IPv4 Multicast Address Assignments. M. Cotton, L. Vegoda, D. Meyer. March 2010. (Format: TXT=22239 bytes) (Obsoletes RFC3138, RFC3171) (Updates RFC2780) (Also BCP0051) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5774.txt 5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition. K. Wolf, A. Mayrhofer. March 2010. (Format: TXT=68468 bytes) (Updates RFC4776) (Also BCP0154) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5855.txt 5855 Nameservers for IPv4 and IPv6 Reverse Zones. J. Abley, T. Manderson. May 2010. (Format: TXT=23027 bytes) (Also BCP0155) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6056.txt 6056 Recommendations for Transport-Protocol Port Randomization. M. Larsen, F. Gont. January 2011. (Format: TXT=63913 bytes) (Also BCP0156) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6158.txt 6158 RADIUS Design Guidelines. A. DeKok, Ed., G. Weber. March 2011. (Format: TXT=89319 bytes) (Also BCP0158) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6177.txt 6177 IPv6 Address Assignment to End Sites. T. Narten, G. Huston, L. Roberts. March 2011. (Format: TXT=21231 bytes) (Obsoletes RFC3177) (Also BCP0157) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6191.txt 6191 Reducing the TIME-WAIT State Using TCP Timestamps. F. Gont. April 2011. (Format: TXT=22953 bytes) (Also BCP0159) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6195.txt 6195 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. March 2011. (Format: TXT=33790 bytes) (Obsoletes RFC5395) (Updates RFC1183, RFC3597) (Also BCP0042) (Status: BEST CURRENT PRACTICE) --Apple-Mail-93--700698807 Content-Disposition: attachment; filename=bcps-in-numeric-order.txt Content-Type: text/plain; name="bcps-in-numeric-order.txt" Content-Transfer-Encoding: 7bit http://www.ietf.org/rfc/rfc1915.txt 1915 Variance for The PPP Compression Control Protocol and The PPP Encryption Control Protocol. F. Kastenholz. February 1996. (Format: TXT=14347 bytes) (Also BCP0003) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc1917.txt 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA. P. Nesser II. February 1996. (Format: TXT=23623 bytes) (Also BCP0004) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc1918.txt 1918 Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc1930.txt 1930 Guidelines for creation, selection, and registration of an Autonomous System (AS). J. Hawkinson, T. Bates. March 1996. (Format: TXT=22073 bytes) (Also BCP0006) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2008.txt 2008 Implications of Various Address Allocation Policies for Internet Routing. Y. Rekhter, T. Li. October 1996. (Format: TXT=34717 bytes) (Also BCP0007) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2014.txt 2014 IRTF Research Group Guidelines and Procedures. A. Weinrib, J. Postel. October 1996. (Format: TXT=27507 bytes) (Also BCP0008) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2026.txt 2026 The Internet Standards Process -- Revision 3. S. Bradner. October 1996. (Format: TXT=86731 bytes) (Obsoletes RFC1602, RFC1871) (Updated by RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC5657, RFC5742) (Also BCP0009) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5657.txt 5657 Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard. L. Dusseault, R. Sparks. September 2009. (Format: TXT=29327 bytes) (Updates RFC2026) (Also BCP0009) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3777.txt 3777 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees. J. Galvin, Ed.. June 2004. (Format: TXT=76395 bytes) (Obsoletes RFC2727) (Updated by RFC5078, RFC5633, RFC5680) (Also BCP0010) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5633.txt 5633 Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers. S. Dawkins, Ed.. August 2009. (Format: TXT=11117 bytes) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5680.txt 5680 The Nominating Committee Process: Open Disclosure of Willing Nominees. S. Dawkins, Ed.. October 2009. (Format: TXT=14296 bytes) (Updates RFC3777) (Also BCP0010) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2028.txt 2028 The Organizations Involved in the IETF Standards Process. R. Hovey, S. Bradner. October 1996. (Format: TXT=13865 bytes) (Updated by RFC3668, RFC3979) (Also BCP0011) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2050.txt 2050 Internet Registry IP Allocation Guidelines. K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel. November 1996. (Format: TXT=28975 bytes) (Obsoletes RFC1466) (Also BCP0012) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4288.txt 4288 Media Type Specifications and Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT=52667 bytes) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4289.txt 4289 Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. N. Freed, J. Klensin. December 2005. (Format: TXT=21502 bytes) (Obsoletes RFC2048) (Also BCP0013) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2119.txt 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. (Format: TXT=4723 bytes) (Also BCP0014) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2148.txt 2148 Deployment of the Internet White Pages Service. H. Alvestrand, P. Jurg. September 1997. (Format: TXT=31539 bytes) (Also BCP0015) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2182.txt 2182 Selection and Operation of Secondary DNS Servers. R. Elz, R. Bush, S. Bradner, M. Patton. July 1997. (Format: TXT=27456 bytes) (Also BCP0016) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2219.txt 2219 Use of DNS Aliases for Network Services. M. Hamilton, R. Wright. October 1997. (Format: TXT=17858 bytes) (Also BCP0017) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2277.txt 2277 IETF Policy on Character Sets and Languages. H. Alvestrand. January 1998. (Format: TXT=16622 bytes) (Also BCP0018) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2978.txt 2978 IANA Charset Registration Procedures. N. Freed, J. Postel. October 2000. (Format: TXT=21615 bytes) (Obsoletes RFC2278) (Also BCP0019) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2317.txt 2317 Classless IN-ADDR.ARPA delegation. H. Eidnes, G. de Groot, P. Vixie. March 1998. (Format: TXT=17744 bytes) (Also BCP0020) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2350.txt 2350 Expectations for Computer Security Incident Response. N. Brownlee, E. Guttman. June 1998. (Format: TXT=86545 bytes) (Also BCP0021) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2360.txt 2360 Guide for Internet Standards Writers. G. Scott. June 1998. (Format: TXT=47280 bytes) (Also BCP0022) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2365.txt 2365 Administratively Scoped IP Multicast. D. Meyer. July 1998. (Format: TXT=17770 bytes) (Also BCP0023) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2379.txt 2379 RSVP over ATM Implementation Guidelines. L. Berger. August 1998. (Format: TXT=15174 bytes) (Also BCP0024) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2418.txt 2418 IETF Working Group Guidelines and Procedures. S. Bradner. September 1998. (Format: TXT=62857 bytes) (Obsoletes RFC1603) (Updated by RFC3934) (Also BCP0025) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5226.txt 5226 Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. May 2008. (Format: TXT=66160 bytes) (Obsoletes RFC2434) (Also BCP0026) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2438.txt 2438 Advancement of MIB specifications on the IETF Standards Track. M. O'Dell, H. Alvestrand, B. Wijnen, S. Bradner. October 1998. (Format: TXT=13633 bytes) (Also BCP0027) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2488.txt 2488 Enhancing TCP Over Satellite Channels using Standard Mechanisms. M. Allman, D. Glover, L. Sanchez. January 1999. (Format: TXT=47857 bytes) (Also BCP0028) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2505.txt 2505 Anti-Spam Recommendations for SMTP MTAs. G. Lindberg. February 1999. (Format: TXT=53597 bytes) (Also BCP0030) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2506.txt 2506 Media Feature Tag Registration Procedure. K. Holtman, A. Mutz, T. Hardie. March 1999. (Format: TXT=24892 bytes) (Also BCP0031) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2606.txt 2606 Reserved Top Level DNS Names. D. Eastlake 3rd, A. Panitz. June 1999. (Format: TXT=8008 bytes) (Also BCP0032) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2644.txt 2644 Changing the Default for Directed Broadcasts in Routers. D. Senie. August 1999. (Format: TXT=6820 bytes) (Updates RFC1812) (Also BCP0034) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4395.txt 4395 Guidelines and Registration Procedures for New URI Schemes. T. Hansen, T. Hardie, L. Masinter. February 2006. (Format: TXT=31933 bytes) (Obsoletes RFC2717, RFC2718) (Also BCP0035) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2736.txt 2736 Guidelines for Writers of RTP Payload Format Specifications. M. Handley, C. Perkins. December 1999. (Format: TXT=24143 bytes) (Also BCP0036) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2780.txt 2780 IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers. S. Bradner, V. Paxson. March 2000. (Format: TXT=18954 bytes) (Updated by RFC4443, RFC5237, RFC5771) (Also BCP0037) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5237.txt 5237 IANA Allocation Guidelines for the Protocol Field. J. Arkko, S. Bradner. February 2008. (Format: TXT=9303 bytes) (Updates RFC2780) (Also BCP0037) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2827.txt 2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2850.txt 2850 Charter of the Internet Architecture Board (IAB). Internet Architecture Board, B. Carpenter, Ed.. May 2000. (Format: TXT=15984 bytes) (Obsoletes RFC1601) (Also BCP0039) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2870.txt 2870 Root Name Server Operational Requirements. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. June 2000. (Format: TXT=21133 bytes) (Obsoletes RFC2010) (Also BCP0040) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2914.txt 2914 Congestion Control Principles. S. Floyd. September 2000. (Format: TXT=43823 bytes) (Also BCP0041) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6195.txt 6195 Domain Name System (DNS) IANA Considerations. D. Eastlake 3rd. March 2011. (Format: TXT=33790 bytes) (Obsoletes RFC5395) (Updates RFC1183, RFC3597) (Also BCP0042) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2939.txt 2939 Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types. R. Droms. September 2000. (Format: TXT=13631 bytes) (Obsoletes RFC2489) (Also BCP0043) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc2964.txt 2964 Use of HTTP State Management. K. Moore, N. Freed. October 2000. (Format: TXT=18899 bytes) (Also BCP0044) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3005.txt 3005 IETF Discussion List Charter. S. Harris. November 2000. (Format: TXT=5682 bytes) (Also BCP0045) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3013.txt 3013 Recommended Internet Service Provider Security Services and Procedures. T. Killalea. November 2000. (Format: TXT=27905 bytes) (Also BCP0046) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4647.txt 4647 Matching of Language Tags. A. Phillips, M. Davis. September 2006. (Format: TXT=45595 bytes) (Obsoletes RFC3066) (Also BCP0047) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5646.txt 5646 Tags for Identifying Languages. A. Phillips, Ed., M. Davis, Ed.. September 2009. (Format: TXT=208592 bytes) (Obsoletes RFC4646) (Also BCP0047) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3150.txt 3150 End-to-end Performance Implications of Slow Links. S. Dawkins, G. Montenegro, M. Kojo, V. Magret. July 2001. (Format: TXT=39942 bytes) (Also BCP0048) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3155.txt 3155 End-to-end Performance Implications of Links with Errors. S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya. August 2001. (Format: TXT=36388 bytes) (Also BCP0050) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5771.txt 5771 IANA Guidelines for IPv4 Multicast Address Assignments. M. Cotton, L. Vegoda, D. Meyer. March 2010. (Format: TXT=22239 bytes) (Obsoletes RFC3138, RFC3171) (Updates RFC2780) (Also BCP0051) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3172.txt 3172 Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa"). G. Huston, Ed.. September 2001. (Format: TXT=18097 bytes) (Also BCP0052) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3180.txt 3180 GLOP Addressing in 233/8. D. Meyer, P. Lothberg. September 2001. (Format: TXT=8225 bytes) (Obsoletes RFC2770) (Also BCP0053) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3184.txt 3184 IETF Guidelines for Conduct. S. Harris. October 2001. (Format: TXT=7413 bytes) (Also BCP0054) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3227.txt 3227 Guidelines for Evidence Collection and Archiving. D. Brezinski, T. Killalea. February 2002. (Format: TXT=18468 bytes) (Also BCP0055) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3205.txt 3205 On the use of HTTP as a Substrate. K. Moore. February 2002. (Format: TXT=34785 bytes) (Also BCP0056) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3228.txt 3228 IANA Considerations for IPv4 Internet Group Management Protocol (IGMP). B. Fenner. February 2002. (Format: TXT=6473 bytes) (Also BCP0057) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3233.txt 3233 Defining the IETF. P. Hoffman, S. Bradner. February 2002. (Format: TXT=6401 bytes) (Also BCP0058) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3349.txt 3349 A Transient Prefix for Identifying Profiles under Development by the Working Groups of the Internet Engineering Task Force. M. Rose. July 2002. (Format: TXT=7916 bytes) (Also BCP0059) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3360.txt 3360 Inappropriate TCP Resets Considered Harmful. S. Floyd. August 2002. (Format: TXT=46748 bytes) (Also BCP0060) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3365.txt 3365 Strong Security Requirements for Internet Engineering Task Force Standard Protocols. J. Schiller. August 2002. (Format: TXT=16411 bytes) (Also BCP0061) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3366.txt 3366 Advice to link designers on link Automatic Repeat reQuest (ARQ). G. Fairhurst, L. Wood. August 2002. (Format: TXT=66097 bytes) (Also BCP0062) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3372.txt 3372 Session Initiation Protocol for Telephones (SIP-T): Context and Architectures. A. Vemuri, J. Peterson. September 2002. (Format: TXT=49893 bytes) (Also BCP0063) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4520.txt 4520 Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP). K. Zeilenga. June 2006. (Format: TXT=34298 bytes) (Obsoletes RFC3383) (Also BCP0064) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3405.txt 3405 Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures. M. Mealling. October 2002. (Format: TXT=19469 bytes) (Also BCP0065) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3406.txt 3406 Uniform Resource Names (URN) Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom. October 2002. (Format: TXT=43707 bytes) (Obsoletes RFC2611) (Also BCP0066) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5727.txt 5727 Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area. J. Peterson, C. Jennings, R. Sparks. March 2010. (Format: TXT=35033 bytes) (Obsoletes RFC3427) (Updates RFC3265, RFC3969) (Also BCP0067) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3438.txt 3438 Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update. W. Townsley. December 2002. (Format: TXT=9135 bytes) (Also BCP0068) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3449.txt 3449 TCP Performance Implications of Network Path Asymmetry. H. Balakrishnan, V. Padmanabhan, G. Fairhurst, M. Sooriyabandara. December 2002. (Format: TXT=108839 bytes) (Also BCP0069) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3470.txt 3470 Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols. S. Hollenbeck, M. Rose, L. Masinter. January 2003. (Format: TXT=64252 bytes) (Also BCP0070) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3481.txt 3481 TCP over Second (2.5G) and Third (3G) Generation Wireless Networks. H. Inamura, Ed., G. Montenegro, Ed., R. Ludwig, A. Gurtov, F. Khafizov. February 2003. (Format: TXT=61528 bytes) (Also BCP0071) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3552.txt 3552 Guidelines for Writing RFC Text on Security Considerations. E. Rescorla, B. Korver. July 2003. (Format: TXT=110393 bytes) (Also BCP0072) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3553.txt 3553 An IETF URN Sub-namespace for Registered Protocol Parameters. M. Mealling, L. Masinter, T. Hardie, G. Klyne. June 2003. (Format: TXT=14815 bytes) (Also BCP0073) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3584.txt 3584 Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework. R. Frye, D. Levi, S. Routhier, B. Wijnen. August 2003. (Format: TXT=115222 bytes) (Obsoletes RFC2576) (Also BCP0074) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3665.txt 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT=163159 bytes) (Also BCP0075) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3666.txt 3666 Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows. A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers. December 2003. (Format: TXT=200478 bytes) (Also BCP0076) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3677.txt 3677 IETF ISOC Board of Trustee Appointment Procedures. L. Daigle, Ed., Internet Architecture Board. December 2003. (Format: TXT=13008 bytes) (Also BCP0077) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5378.txt 5378 Rights Contributors Provide to the IETF Trust. S. Bradner, Ed., J. Contreras, Ed.. November 2008. (Format: TXT=37980 bytes) (Obsoletes RFC3978, RFC4748) (Updates RFC2026) (Also BCP0078) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3979.txt 3979 Intellectual Property Rights in IETF Technology. S. Bradner, Ed.. March 2005. (Format: TXT=41366 bytes) (Obsoletes RFC3668) (Updates RFC2026, RFC2028) (Updated by RFC4879) (Also BCP0079) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4879.txt 4879 Clarification of the Third Party Disclosure Procedure in RFC 3979. T. Narten. April 2007. (Format: TXT=5570 bytes) (Updates RFC3979) (Also BCP0079) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3681.txt 3681 Delegation of E.F.F.3.IP6.ARPA. R. Bush, R. Fink. January 2004. (Format: TXT=7137 bytes) (Also BCP0080) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3688.txt 3688 The IETF XML Registry. M. Mealling. January 2004. (Format: TXT=17325 bytes) (Also BCP0081) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3692.txt 3692 Assigning Experimental and Testing Numbers Considered Useful. T. Narten. January 2004. (Format: TXT=15054 bytes) (Updates RFC2434) (Also BCP0082) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3683.txt 3683 A Practice for Revoking Posting Rights to IETF Mailing Lists. M. Rose. March 2004. (Format: TXT=15698 bytes) (Also BCP0083) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3704.txt 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also BCP0084) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3725.txt 3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP). J. Rosenberg, J. Peterson, H. Schulzrinne, G. Camarillo. April 2004. (Format: TXT=77308 bytes) (Also BCP0085) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3766.txt 3766 Determining Strengths For Public Keys Used For Exchanging Symmetric Keys. H. Orman, P. Hoffman. April 2004. (Format: TXT=55939 bytes) (Also BCP0086) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3785.txt 3785 Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric. F. Le Faucheur, R. Uppili, A. Vedrenne, P. Merckx, T. Telkamp. May 2004. (Format: TXT=17475 bytes) (Also BCP0087) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3818.txt 3818 IANA Considerations for the Point-to-Point Protocol (PPP). V. Schryver. June 2004. (Format: TXT=6321 bytes) (Also BCP0088) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3819.txt 3819 Advice for Internet Subnetwork Designers. P. Karn, Ed., C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood. July 2004. (Format: TXT=152174 bytes) (Also BCP0089) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3864.txt 3864 Registration Procedures for Message Header Fields. G. Klyne, M. Nottingham, J. Mogul. September 2004. (Format: TXT=36231 bytes) (Also BCP0090) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3901.txt 3901 DNS IPv6 Transport Operational Guidelines. A. Durand, J. Ihren. September 2004. (Format: TXT=10025 bytes) (Also BCP0091) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5742.txt 5742 IESG Procedures for Handling of Independent and IRTF Stream Submissions. H. Alvestrand, R. Housley. December 2009. (Format: TXT=21067 bytes) (Obsoletes RFC3932) (Updates RFC2026, RFC3710) (Also BCP0092) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3933.txt 3933 A Model for IETF Process Experiments. J. Klensin, S. Dawkins. November 2004. (Format: TXT=14409 bytes) (Also BCP0093) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3934.txt 3934 Updates to RFC 2418 Regarding the Management of IETF Mailing Lists. M. Wasserman. October 2004. (Format: TXT=8488 bytes) (Updates RFC2418) (Also BCP0094) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3935.txt 3935 A Mission Statement for the IETF. H. Alvestrand. October 2004. (Format: TXT=16639 bytes) (Also BCP0095) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3936.txt 3936 Procedures for Modifying the Resource reSerVation Protocol (RSVP). K. Kompella, J. Lang. October 2004. (Format: TXT=15314 bytes) (Updates RFC3209, RFC2205) (Also BCP0096) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3967.txt 3967 Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level. R. Bush, T. Narten. December 2004. (Format: TXT=12251 bytes) (Updated by RFC4897) (Also BCP0097) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4897.txt 4897 Handling Normative References to Standards-Track Documents. J. Klensin, S. Hartman. June 2007. (Format: TXT=13023 bytes) (Updates RFC3967) (Also BCP0097) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3968.txt 3968 The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT=20615 bytes) (Updates RFC3427) (Also BCP0098) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc3969.txt 3969 The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP). G. Camarillo. December 2004. (Format: TXT=12119 bytes) (Updates RFC3427) (Updated by RFC5727) (Also BCP0099) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4020.txt 4020 Early IANA Allocation of Standards Track Code Points. K. Kompella, A. Zinin. February 2005. (Format: TXT=13706 bytes) (Also BCP0100) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4071.txt 4071 Structure of the IETF Administrative Support Activity (IASA). R. Austein, Ed., B. Wijnen, Ed.. April 2005. (Format: TXT=48614 bytes) (Updated by RFC4371) (Also BCP0101) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4371.txt 4371 BCP 101 Update for IPR Trust. B. Carpenter, Ed., L. Lynch, Ed.. January 2006. (Format: TXT=6901 bytes) (Updates RFC4071) (Also BCP0101) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4052.txt 4052 IAB Processes for Management of IETF Liaison Relationships. L. Daigle, Ed., Internet Architecture Board. April 2005. (Format: TXT=18360 bytes) (Also BCP0102) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4053.txt 4053 Procedures for Handling Liaison Statements to and from the IETF. S. Trowbridge, S. Bradner, F. Baker. April 2005. (Format: TXT=38816 bytes) (Also BCP0103) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4084.txt 4084 Terminology for Describing Internet Connectivity. J. Klensin. May 2005. (Format: TXT=24522 bytes) (Also BCP0104) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4085.txt 4085 Embedding Globally-Routable Internet Addresses Considered Harmful. D. Plonka. June 2005. (Format: TXT=22656 bytes) (Also BCP0105) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4086.txt 4086 Randomness Requirements for Security. D. Eastlake 3rd, J. Schiller, S. Crocker. June 2005. (Format: TXT=114321 bytes) (Obsoletes RFC1750) (Also BCP0106) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4107.txt 4107 Guidelines for Cryptographic Key Management. S. Bellovin, R. Housley. June 2005. (Format: TXT=14752 bytes) (Also BCP0107) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4159.txt 4159 Deprecation of "ip6.int". G. Huston. August 2005. (Format: TXT=5353 bytes) (Also BCP0109) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4170.txt 4170 Tunneling Multiplexed Compressed RTP (TCRTP). B. Thompson, T. Koren, D. Wing. November 2005. (Format: TXT=48990 bytes) (Also BCP0110) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4181.txt 4181 Guidelines for Authors and Reviewers of MIB Documents. C. Heard, Ed.. September 2005. (Format: TXT=102521 bytes) (Updated by RFC4841) (Also BCP0111) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4841.txt 4841 RFC 4181 Update to Recognize the IETF Trust. C. Heard, Ed.. March 2007. (Format: TXT=4414 bytes) (Updates RFC4181) (Also BCP0111) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4222.txt 4222 Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance. G. Choudhury, Ed.. October 2005. (Format: TXT=34132 bytes) (Also BCP0112) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4333.txt 4333 The IETF Administrative Oversight Committee (IAOC) Member Selection Guidelines and Process. G. Huston, Ed., B. Wijnen, Ed.. December 2005. (Format: TXT=15396 bytes) (Also BCP0113) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4384.txt 4384 BGP Communities for Data Collection. D. Meyer. February 2006. (Format: TXT=26078 bytes) (Also BCP0114) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4446.txt 4446 IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3). L. Martini. April 2006. (Format: TXT=19782 bytes) (Also BCP0116) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4497.txt 4497 Interworking between the Session Initiation Protocol (SIP) and QSIG. J. Elwell, F. Derks, P. Mourot, O. Rousseau. May 2006. (Format: TXT=149992 bytes) (Also BCP0117) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4521.txt 4521 Considerations for Lightweight Directory Access Protocol (LDAP) Extensions. K. Zeilenga. June 2006. (Format: TXT=34585 bytes) (Also BCP0118) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4579.txt 4579 Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents. A. Johnston, O. Levin. August 2006. (Format: TXT=96506 bytes) (Also BCP0119) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4608.txt 4608 Source-Specific Protocol Independent Multicast in 232/8. D. Meyer, R. Rockell, G. Shepherd. August 2006. (Format: TXT=15030 bytes) (Also BCP0120) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4611.txt 4611 Multicast Source Discovery Protocol (MSDP) Deployment Scenarios. M. McBride, J. Meylor, D. Meyer. August 2006. (Format: TXT=33230 bytes) (Also BCP0121) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4632.txt 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT=66944 bytes) (Obsoletes RFC1519) (Also BCP0122) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4697.txt 4697 Observed DNS Resolution Misbehavior. M. Larson, P. Barber. October 2006. (Format: TXT=45187 bytes) (Also BCP0123) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4774.txt 4774 Specifying Alternate Semantics for the Explicit Congestion Notification (ECN) Field. S. Floyd. November 2006. (Format: TXT=37144 bytes) (Updated by RFC6040) (Also BCP0124) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4775.txt 4775 Procedures for Protocol Extensions and Variations. S. Bradner, B. Carpenter, Ed., T. Narten. December 2006. (Format: TXT=32797 bytes) (Also BCP0125) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4786.txt 4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT=56818 bytes) (Also BCP0126) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4787.txt 4787 Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. F. Audet, Ed., C. Jennings. January 2007. (Format: TXT=68693 bytes) (Also BCP0127) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4928.txt 4928 Avoiding Equal Cost Multipath Treatment in MPLS Networks. G. Swallow, S. Bryant, L. Andersson. June 2007. (Format: TXT=18376 bytes) (Also BCP0128) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4929.txt 4929 Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures. L. Andersson, Ed., A. Farrel, Ed.. June 2007. (Format: TXT=56742 bytes) (Also BCP0129) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4940.txt 4940 IANA Considerations for OSPF. K. Kompella, B. Fenner. July 2007. (Format: TXT=27595 bytes) (Also BCP0130) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4961.txt 4961 Symmetric RTP / RTP Control Protocol (RTCP). D. Wing. July 2007. (Format: TXT=12539 bytes) (Also BCP0131) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc4962.txt 4962 Guidance for Authentication, Authorization, and Accounting (AAA) Key Management. R. Housley, B. Aboba. July 2007. (Format: TXT=54927 bytes) (Also BCP0132) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5033.txt 5033 Specifying New Congestion Control Algorithms. S. Floyd, M. Allman. August 2007. (Format: TXT=23469 bytes) (Also BCP0133) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5068.txt 5068 Email Submission Operations: Access and Accountability Requirements. C. Hutzler, D. Crocker, P. Resnick, E. Allman, T. Finch. November 2007. (Format: TXT=24481 bytes) (Also BCP0134) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5135.txt 5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT). D. Wing, T. Eckert. February 2008. (Format: TXT=36528 bytes) (Also BCP0135) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5266.txt 5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE). V. Devarapalli, P. Eronen. June 2008. (Format: TXT=33186 bytes) (Also BCP0136) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5137.txt 5137 ASCII Escaping of Unicode Characters. J. Klensin. February 2008. (Format: TXT=27742 bytes) (Also BCP0137) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5248.txt 5248 A Registry for SMTP Enhanced Mail System Status Codes. T. Hansen, J. Klensin. June 2008. (Format: TXT=23845 bytes) (Updates RFC3463, RFC4468, RFC4954) (Also BCP0138) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5249.txt 5249 Templates for Internet-Drafts Containing MIB Modules. D. Harrington, Ed.. July 2008. (Format: TXT=7362 bytes) (Also BCP0139) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5358.txt 5358 Preventing Use of Recursive Nameservers in Reflector Attacks. J. Damas, F. Neves. October 2008. (Format: TXT=14957 bytes) (Also BCP0140) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5342.txt 5342 IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters. D. Eastlake 3rd. September 2008. (Format: TXT=42800 bytes) (Updates RFC2153) (Also BCP0141) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5382.txt 5382 NAT Behavioral Requirements for TCP. S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh. October 2008. (Format: TXT=50306 bytes) (Also BCP0142) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5383.txt 5383 Deployment Considerations for Lemonade-Compliant Mobile Email. R. Gellens. October 2008. (Format: TXT=28290 bytes) (Also BCP0143) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5359.txt 5359 Session Initiation Protocol Service Examples. A. Johnston, Ed., R. Sparks, C. Cunningham, S. Donovan, K. Summers. October 2008. (Format: TXT=289446 bytes) (Also BCP0144) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5405.txt 5405 Unicast UDP Usage Guidelines for Application Designers. L. Eggert, G. Fairhurst. November 2008. (Format: TXT=69607 bytes) (Also BCP0145) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5406.txt 5406 Guidelines for Specifying the Use of IPsec Version 2. S. Bellovin. February 2009. (Format: TXT=30393 bytes) (Also BCP0146) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5407.txt 5407 Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP). M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P. Kyzivat. December 2008. (Format: TXT=120005 bytes) (Also BCP0147) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5508.txt 5508 NAT Behavioral Requirements for ICMP. P. Srisuresh, B. Ford, S. Sivakumar, S. Guha. April 2009. (Format: TXT=67985 bytes) (Also BCP0148) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5589.txt 5589 Session Initiation Protocol (SIP) Call Control - Transfer. R. Sparks, A. Johnston, Ed., D. Petrie. June 2009. (Format: TXT=119434 bytes) (Also BCP0149) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5597.txt 5597 Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol. R. Denis-Courmont. September 2009. (Format: TXT=18933 bytes) (Also BCP0150) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5615.txt 5615 H.248/MEGACO Registration Procedures. C. Groves, Y. Lin. August 2009. (Format: TXT=29069 bytes) (Also BCP0151) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5625.txt 5625 DNS Proxy Implementation Guidelines. R. Bellis. August 2009. (Format: TXT=24585 bytes) (Also BCP0152) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5735.txt 5735 Special Use IPv4 Addresses. M. Cotton, L. Vegoda. January 2010. (Format: TXT=20369 bytes) (Obsoletes RFC3330) (Also BCP0153) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5774.txt 5774 Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition. K. Wolf, A. Mayrhofer. March 2010. (Format: TXT=68468 bytes) (Updates RFC4776) (Also BCP0154) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc5855.txt 5855 Nameservers for IPv4 and IPv6 Reverse Zones. J. Abley, T. Manderson. May 2010. (Format: TXT=23027 bytes) (Also BCP0155) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6056.txt 6056 Recommendations for Transport-Protocol Port Randomization. M. Larsen, F. Gont. January 2011. (Format: TXT=63913 bytes) (Also BCP0156) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6177.txt 6177 IPv6 Address Assignment to End Sites. T. Narten, G. Huston, L. Roberts. March 2011. (Format: TXT=21231 bytes) (Obsoletes RFC3177) (Also BCP0157) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6158.txt 6158 RADIUS Design Guidelines. A. DeKok, Ed., G. Weber. March 2011. (Format: TXT=89319 bytes) (Also BCP0158) (Status: BEST CURRENT PRACTICE) http://www.ietf.org/rfc/rfc6191.txt 6191 Reducing the TIME-WAIT State Using TCP Timestamps. F. Gont. April 2011. (Format: TXT=22953 bytes) (Also BCP0159) (Status: BEST CURRENT PRACTICE) --Apple-Mail-93--700698807 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The other thing that I do is ask myself what there is to know about a = particular topic, which might mean to search the IEN and RFC series for = documents that mention "multihom" (eg, multihome, multihoming, = multihomed), for example, and then go look at what they say. That is a = place for fgrep, but "gee wouldn't it be nice" if we could somehow = identify those files and pop up a web page something akin to the = attached file "multihoming-search.txt". No, my hack tool doesn't = generate this easily, but it was used in generating this example. The = value of the web page is to help someone zero in quickly on the document = s/he needs to read and give him/her a link to find it. --Apple-Mail-93--700698807 Content-Disposition: attachment; filename=multihoming-search.txt Content-Type: text/plain; name="multihoming-search.txt" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/rfc/ien/ien110.txt 3. Hosts which are deliberately multihomed on distinct networks should be able to recover from interface failures, but by mechanisms above the TCP/internet layer, not within them. http://www.ietf.org/rfc/ien/ien145.txt Carl Sunshine presented an alternate strategy for dealing with mobile hosts which makes the hosts do most of the work. This scheme uses the existing IP source routing option and a new GCP message. It calls for a new host (or special functions in an existing host or gateway) to support (1) forwarding and (2) a global name server. New messages are needed in the gateway protocol (IEN 109) to relay information about a mobile host's current location to the name server and the "connected" hosts. This procedure is described in IEN 135. This procedure may also be workable for multihomed hosts and as a least effort solution to the partition problem. http://www.ietf.org/rfc/ien/ien178.txt To allow uers in different networks to communicate with each other, development of powerful yet practical naming, addressing, and routing facilities is essential. Basic procedures for multi-network systems under control of a single organization have begun to be used, but a large set of more sophisticated goals remain to be addressed. This paper describes several of these more advanced problems including extendability, multihoming, network partitioning, mobile hosts, shared access, local site connections, gateway routing, and overcoming differences in heterogeneous systems. more sophisticated functions such as multihoming, network=0C= Multihoming source. To obtain the benefits of multihoming, the discussed above under Multihoming. http://www.ietf.org/rfc/ien/ien179.txt Such a scheme yields tables of reasonable size, can benefit from any structure and logic/regularity (as opposed to randomness) of the communication subsystem, can handle multihoming, and has the capability to utilize special irregular HU lines and shortcuts. http://www.ietf.org/rfc/rfc0898.txt 0898 Gateway special interest group meeting notes. R.M. Hinden, J. Postel, M. Muuss, J.K. Reynolds. April 1984. (Format: TXT=3D42112 bytes) (Status: UNKNOWN) 1. Direct: code --> subnet 2. Redirect: 2nd lookup (for multihoming) 3. Logical: Logical address into a table of universe names. Name lookups give addresses and routes. SAM does access control and multihoming. Clever Multihoming gives host a second address and sends an ICMP/Redirect to force TCP connection to go through a different route, but wind up at same place!!! http://www.ietf.org/rfc/rfc0940.txt 0940 Toward an Internet standard scheme for subnetting. Gateway Algorithms and Data Structures Task Force. April 1985. (Format: TXT=3D6881 bytes) (Status: UNKNOWN) The above procedure must be treated as a per interface procedure for multihomed hosts. http://www.ietf.org/rfc/rfc1009.txt 1009 Requirements for Internet gateways. R.T. Braden, J. Postel. June 1987. (Format: TXT=3D128173 bytes) (Obsoletes RFC0985) (Obsoleted = by RFC1812) (Status: HISTORIC) 2. If a (multihomed) host acts as a gateway, it must implement ALL the relevant gateway requirements contained in this document. Multihoming is possible on one wide-area network, but may present routing problems if the interfaces are geographically or topologically separated. Multihoming on two (or more) wide-area networks is a problem due to the confusion of addresses. http://www.ietf.org/rfc/rfc1034.txt 1034 Domain names - concepts and facilities. P.V. Mockapetris. November 1987. (Format: TXT=3D129180 bytes) (Obsoletes RFC0973, RFC0882, RFC0883) (Updated by RFC1101, RFC1183, RFC1348, RFC1876, RFC1982, RFC2065, RFC2181, RFC2308, RFC2535, RFC4033, RFC4034, RFC4035, RFC4343, RFC4035, RFC4592, RFC5936) (Also STD0013) = (Status: STANDARD) Step 3 sends out queries until a response is received. The strategy is to cycle around all of the addresses for all of the servers with a timeout between each transmission. In practice it is important to use all addresses of a multihomed host, and too aggressive a retransmission policy actually slows response when used by multiple resolvers contending for the same name server and even occasionally for a single resolver. SLIST typically contains data values to control the timeouts and keep track of previous transmissions. http://www.ietf.org/rfc/rfc1070.txt 1070 Use of the Internet as a subnetwork for experimentation with the OSI network layer. R.A. Hagens, N.E. Hall, M.T. Rose. February = 1989. (Format: TXT=3D37354 bytes) (Status: UNKNOWN) # # hosts.EON hypothetical EON topology # 128.105.4.150 # ES in cs.wisc.edu 128.105.2.150 # same as above : multihomed ES 128.105.4.154 # ES in cs.wisc.edu 128.105.4.151 # ES in cs.wisc.edu 128.105.2.153 # IS/ES in cs.wisc.edu 26.5.0.73 # ES in cs.tudor.edu 192.5.2.2 # ES in cs.fordor.edu http://www.ietf.org/rfc/rfc1122.txt 1122 Requirements for Internet Hosts - Communication Layers. R. Braden, Ed.. October 1989. (Format: TXT=3D295992 bytes) (Updates RFC0793) (Updated by RFC1349, RFC4379, RFC5884, RFC6093) (Also STD0003) (Status: STANDARD) 3. INTERNET LAYER PROTOCOLS .................................... 27 3.1 INTRODUCTION ............................................ 27 3.2 PROTOCOL WALK-THROUGH .................................. 29 3.2.1 Internet Protocol -- IP ............................ 29 3.2.1.1 Version Number ............................... 29 3.2.1.2 Checksum ..................................... 29 3.2.1.3 Addressing ................................... 29 3.2.1.4 Fragmentation and Reassembly ................. 32 3.2.1.5 Identification ............................... 32 3.2.1.6 Type-of-Service .............................. 33 3.2.1.7 Time-to-Live ................................. 34 3.2.1.8 Options ...................................... 35 3.2.2 Internet Control Message Protocol -- ICMP .......... 38 3.2.2.1 Destination Unreachable ...................... 39 3.2.2.2 Redirect ..................................... 40 3.2.2.3 Source Quench ................................ 41 3.2.2.4 Time Exceeded ................................ 41 3.2.2.5 Parameter Problem ............................ 42 3.2.2.6 Echo Request/Reply ........................... 42 3.2.2.7 Information Request/Reply .................... 43 3.2.2.8 Timestamp and Timestamp Reply ................ 43 3.2.2.9 Address Mask Request/Reply ................... 45 3.2.3 Internet Group Management Protocol IGMP ........... 47 3.3 SPECIFIC ISSUES ........................................ 47 3.3.1 Routing Outbound Datagrams ........................ 47 3.3.1.1 Local/Remote Decision ........................ 47 3.3.1.2 Gateway Selection ............................ 48 3.3.1.3 Route Cache .................................. 49 3.3.1.4 Dead Gateway Detection ....................... 51 3.3.1.5 New Gateway Selection ........................ 55 3.3.1.6 Initialization ............................... 56 3.3.2 Reassembly ........................................ 56 3.3.3 Fragmentation ..................................... 58 3.3.4 Local Multihoming ................................. 60 3.3.4.1 Introduction ................................. 60 3.3.4.2 Multihoming Requirements ..................... 61 3.3.4.3 Choosing a Source Address .................... 64 3.3.5 Source Route Forwarding ........................... 65 4. TRANSPORT PROTOCOLS ......................................... 77 4.1 USER DATAGRAM PROTOCOL -- UDP .......................... 77 4.1.1 INTRODUCTION ...................................... 77 4.1.2 PROTOCOL WALK-THROUGH ............................. 77 4.1.3 SPECIFIC ISSUES ................................... 77 4.1.3.1 Ports ........................................ 77 4.1.3.2 IP Options ................................... 77 4.1.3.3 ICMP Messages ................................ 78 4.1.3.4 UDP Checksums ................................ 78 4.1.3.5 UDP Multihoming .............................. 79 4.1.3.6 Invalid Addresses ............................ 79 4.1.4 UDP/APPLICATION LAYER INTERFACE ................... 79 4.1.5 UDP REQUIREMENTS SUMMARY .......................... 80 4.2 TRANSMISSION CONTROL PROTOCOL -- TCP ................... 82 4.2.1 INTRODUCTION ...................................... 82 4.2.2 PROTOCOL WALK-THROUGH ............................. 82 4.2.2.1 Well-Known Ports ............................. 82 4.2.2.2 Use of Push .................................. 82 4.2.2.3 Window Size .................................. 83 4.2.2.4 Urgent Pointer ............................... 84 4.2.2.5 TCP Options .................................. 85 4.2.2.6 Maximum Segment Size Option .................. 85 4.2.2.7 TCP Checksum ................................. 86 4.2.2.8 TCP Connection State Diagram ................. 86 4.2.2.9 Initial Sequence Number Selection ............ 87 4.2.2.10 Simultaneous Open Attempts .................. 87 4.2.2.11 Recovery from Old Duplicate SYN ............. 87 4.2.2.12 RST Segment ................................. 87 4.2.2.13 Closing a Connection ........................ 87 4.2.2.14 Data Communication .......................... 89 4.2.2.15 Retransmission Timeout ...................... 90 4.2.2.16 Managing the Window ......................... 91 4.2.2.17 Probing Zero Windows ........................ 92 4.2.2.18 Passive OPEN Calls .......................... 92 4.2.2.19 Time to Live ................................ 93 4.2.2.20 Event Processing ............................ 93 4.2.2.21 Acknowledging Queued Segments ............... 94 4.2.3 SPECIFIC ISSUES ................................... 95 4.2.3.1 Retransmission Timeout Calculation ........... 95 4.2.3.2 When to Send an ACK Segment .................. 96 4.2.3.3 When to Send a Window Update ................. 97 4.2.3.4 When to Send Data ............................ 98 4.2.3.5 TCP Connection Failures ...................... 100 4.2.3.6 TCP Keep-Alives .............................. 101 4.2.3.7 TCP Multihoming .............................. 103 4.2.3.8 IP Options ................................... 103 4.2.3.9 ICMP Messages ................................ 103 4.2.3.10 Remote Address Validation ................... 104 4.2.3.11 TCP Traffic Patterns ........................ 104 4.2.3.12 Efficiency .................................. 105 4.2.4 TCP/APPLICATION LAYER INTERFACE ................... 106 4.2.4.1 Asynchronous Reports ......................... 106 4.2.4.2 Type-of-Service .............................. 107 4.2.4.3 Flush Call ................................... 107 4.2.4.4 Multihoming .................................. 108 4.2.5 TCP REQUIREMENT SUMMARY ........................... 108 A host is generally said to be multihomed if it has more than one interface to the same or to different networks. See Section 1.1.3 on "Terminology". There is also an architectural argument for embedded gateway functionality: multihoming is much more common than originally foreseen, and multihoming forces a host to make routing decisions as if it were a gateway. If the multihomed host contains an embedded gateway, it will have full routing knowledge and as a result will be able to make more optimal routing decisions. Multihomed A host is said to be multihomed if it has multiple IP addresses. For a discussion of multihoming, see Section 3.3.4 below. A host is said to be multihomed if it has multiple IP addresses. Multihoming introduces considerable confusion and complexity into the protocol suite, and it is an area in which the Internet architecture falls seriously short of solving all problems. There are two distinct problem areas in multihoming: (1) Local multihoming -- the host itself is multihomed; or (2) Remote multihoming -- the local host needs to communicate with a remote multihomed host. At present, remote multihoming MUST be handled at the application layer, as discussed in the companion RFC [INTRO:1]. A host MAY support local multihoming, which is discussed in this document, and in particular in Section 3.3.4. non-gateway mode. In this mode, a datagram arriving through one interface will not be forwarded to another host or gateway (unless it is source-routed), regardless of whether the host is single- homed or multihomed. The host software MUST NOT automatically move into gateway mode if the host has more than one interface, as the operator of the machine may neither want to provide that service nor be competent to do so. (a) The address mask (particular to a local IP address for a multihomed host) is a 32-bit mask that selects the network number and subnet number fields of the corresponding IP address. (1) Local IP address (for a multihomed host) See Section 3.3.4.2 for a discussion of the implications of multihoming for the lookup procedure in this cache. A host IP layer implementation MAY have a configuration flag "All-Subnets-MTU", indicating that the MTU of the connected network is to be used for destinations on different subnets within the same network, but not for other networks. Thus, this flag causes the network class mask, rather than the subnet address mask, to be used to choose an EMTU_S. For a multihomed host, an "All-Subnets-MTU" flag is needed for each network interface. 3.3.4 Local Multihoming A multihomed host has multiple IP addresses, which we may think of as "logical interfaces". These logical interfaces may be associated with one or more physical interfaces, and these physical interfaces may be connected to the same or different networks. Here are some important cases of multihoming: (c) Simple Multihoming In this case, each logical interface is mapped into a separate physical interface and each physical interface is connected to a different physical network. The term "multihoming" was originally applied only to this case, but it is now applied more generally. A host with embedded gateway functionality will typically fall into the simple multihoming case. Note, however, that a host may be simply multihomed without containing an embedded gateway, i.e., without forwarding datagrams from one connected network to another. Finally, we note another possibility that is NOT multihoming: one logical interface may be bound to multiple physical interfaces, in order to increase the reliability or throughput between directly connected machines by providing alternative physical paths between them. For instance, two systems might be connected by multiple point-to-point links. We call this "link-layer multiplexing". With link-layer multiplexing, the protocols above the link layer are unaware that multiple physical interfaces are present; the link- layer device driver is responsible for multiplexing and routing packets across the physical interfaces. In the Internet protocol architecture, a transport protocol instance ("entity") has no address of its own, but instead uses a single Internet Protocol (IP) address. This has implications for the IP, transport, and application layers, and for the interfaces between them. In particular, the application software may have to be aware of the multiple IP addresses of a multihomed host; in other cases, the choice can be made within the network software. 3.3.4.2 Multihoming Requirements The following general rules apply to the selection of an IP source address for sending a datagram from a multihomed There are two key requirement issues related to multihoming: DISCUSSION: Internet host implementors have used two different conceptual models for multihoming, briefly summarized in the following discussion. This document takes no stand on which model is preferred; each seems to have a place. This ambivalence is reflected in the issues (A) and (B) being optional. The Strong ES (End System, i.e., host) model emphasizes the host/gateway (ES/IS) distinction, and would therefore substitute MUST for MAY in issues (A) and (B) above. It tends to model a multihomed host as a set of logical hosts within the same physical host. DISCUSSION: When it sends an initial connection request (e.g., a TCP "SYN" segment) or a datagram service request (e.g., a UDP-based query), the transport layer on a multihomed host needs to know which source address to use. If the application does not specify it, the transport layer must ask the IP layer to perform the conceptual mapping: In the future, there may be a defined way for a multihomed host to ask the gateways on all connected networks for advice about the best network to use for a given destination. There has been discussion on whether a datagram addressed to the Limited Broadcast address ought to be sent from all the interfaces of a multihomed host. This specification takes no stand on the issue. | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | Implement IP and ICMP |3.1 |x| | | | | Handle remote multihoming in application layer |3.1 |x| | | | | Support local multihoming |3.1 | | |x| | | Meet gateway specs if forward datagrams |3.1 |x| | | | | Configuration switch for embedded gateway |3.1 |x| | | | |1 Config switch default to non-gateway |3.1 |x| | | | |1 Auto-config based on number of interfaces |3.1 | | | | |x|1 Able to log discarded datagrams |3.1 | |x| | | | Record in counter |3.1 | |x| | | | | | | | | | | Silently discard Version !=3D 4 |3.2.1.1 |x| | | | | Verify IP checksum, silently discard bad dgram |3.2.1.2 |x| | | | | Addressing: | | | | | | | Subnet addressing (RFC-950) |3.2.1.3 |x| | | | | Src address must be host's own IP address |3.2.1.3 |x| | | | | Silently discard datagram with bad dest addr |3.2.1.3 |x| | | | | Silently discard datagram with bad src addr |3.2.1.3 |x| | | | | Support reassembly |3.2.1.4 |x| | | | | Retain same Id field in identical datagram |3.2.1.5 | | |x| | | | | | | | | | TOS: | | | | | | | Allow transport layer to set TOS |3.2.1.6 |x| | | | | Pass received TOS up to transport layer |3.2.1.6 | |x| | | | Use RFC-795 link-layer mappings for TOS |3.2.1.6 | | | |x| | TTL: | | | | | | | Send packet with TTL of 0 |3.2.1.7 | | | | |x| Discard received packets with TTL < 2 |3.2.1.7 | | | | |x| Allow transport layer to set TTL |3.2.1.7 |x| | | | | Fixed TTL is configurable |3.2.1.7 |x| | | | | | | | | | | | IP Options: | | | | | | | Allow transport layer to send IP options |3.2.1.8 |x| | | | | Pass all IP options rcvd to higher layer |3.2.1.8 |x| | | | | Ping gateways continuously |3.3.1.4 | | | | |x| Ping only when traffic being sent |3.3.1.4 |x| | | | | Ping only when no positive indication |3.3.1.4 |x| | | | | Higher and lower layers give advice |3.3.1.4 | |x| | | | Switch from failed default g'way to another |3.3.1.5 |x| | | | | Manual method of entering config info |3.3.1.6 |x| | | | | | | | | | | | REASSEMBLY and FRAGMENTATION: | | | | | | | Able to reassemble incoming datagrams |3.3.2 |x| | | | | At least 576 byte datagrams |3.3.2 |x| | | | | EMTU_R configurable or indefinite |3.3.2 | |x| | | | Transport layer able to learn MMS_R |3.3.2 |x| | | | | Send ICMP Time Exceeded on reassembly timeout |3.3.2 |x| | | | | Fixed reassembly timeout value |3.3.2 | |x| | | | | | | | | | | Pass MMS_S to higher layers |3.3.3 |x| | | | | Local fragmentation of outgoing packets |3.3.3 | | |x| | | Else don't send bigger than MMS_S |3.3.3 |x| | | | | Send max 576 to off-net destination |3.3.3 | |x| | | | All-Subnets-MTU configuration flag |3.3.3 | | |x| | | | | | | | | | MULTIHOMING: | | | | | | | Reply with same addr as spec-dest addr |3.3.4.2 | |x| | | | Allow application to choose local IP addr |3.3.4.2 |x| | | | | Silently discard d'gram in "wrong" interface |3.3.4.2 | | |x| | | Only send d'gram through "right" interface |3.3.4.2 | | |x| | |4 | | | | | | | SOURCE-ROUTE FORWARDING: | | | | | | | Forward datagram with Source Route option |3.3.5 | | |x| | |1 Obey corresponding gateway rules |3.3.5 |x| | | | |1 Update TTL by gateway rules |3.3.5 |x| | | | |1 Able to generate ICMP err code 4, 5 |3.3.5 |x| | | | |1 IP src addr not local host |3.3.5 | | |x| | |1 Update Timestamp, Record Route options |3.3.5 |x| | | | |1 Configurable switch for non-local SRing |3.3.5 |x| | | | |1 Defaults to OFF |3.3.5 |x| | | | |1 Satisfy gwy access rules for non-local SRing |3.3.5 |x| | | | |1 If not forward, send Dest Unreach (cd 5) |3.3.5 | |x| | | |2 | | | | | | | BROADCAST: | | | | | | | Broadcast addr as IP source addr |3.2.1.3 | | | | |x| Receive 0 or -1 broadcast formats OK |3.3.6 | |x| | | | Config'ble option to send 0 or -1 b'cast |3.3.6 | | |x| | | Default to -1 broadcast |3.3.6 | |x| | | | Recognize all broadcast address formats |3.3.6 |x| | | | | Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6 |x| | | | | Silently discard link-layer-only b'cast dg's |3.3.6 | |x| | | | Use Limited Broadcast addr for connected net |3.3.6 | |x| | | | 4.1.3.5 UDP Multihoming | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | UDP | | | | | | | -------------------------------------------------|--------|-|-|-|-|-|-- | | | | | | | UDP send Port Unreachable |4.1.3.1 | |x| | | | | | | | | | | IP Options in UDP | | | | | | | - Pass rcv'd IP options to applic layer |4.1.3.2 |x| | | | | - Applic layer can specify IP options in Send |4.1.3.2 |x| | | | | - UDP passes IP options down to IP layer |4.1.3.2 |x| | | | | | | | | | | | Pass ICMP msgs up to applic layer |4.1.3.3 |x| | | | | | | | | | | | UDP checksums: | | | | | | | - Able to generate/check checksum |4.1.3.4 |x| | | | | - Silently discard bad checksum |4.1.3.4 |x| | | | | - Sender Option to not generate checksum |4.1.3.4 | | |x| | | - Default is to checksum |4.1.3.4 |x| | | | | - Receiver Option to require checksum |4.1.3.4 | | |x| | | | | | | | | | UDP Multihoming | | | | | | | - Pass spec-dest addr to application |4.1.3.5 |x| | | | | 4.2.3.7 TCP Multihoming If an application on a multihomed host does not specify the local IP address when actively opening a TCP connection, then the TCP MUST ask the IP layer to select a local IP address before sending the (first) SYN. See the function GET_SRCADDR() in Section 3.4. 4.2.4.4 Multihoming The user interface outlined in sections 2.7 and 3.8 of RFC- 793 needs to be extended for multihoming. The OPEN call MUST have an optional parameter: http://www.ietf.org/rfc/rfc1123.txt 1123 Requirements for Internet Hosts - Application and Support. R. Braden, Ed.. October 1989. (Format: TXT=3D245503 bytes) (Updates RFC0822) (Updated by RFC1349, RFC2181, RFC5321, RFC5966) (Also STD0003) (Status: STANDARD) 2. GENERAL ISSUES ............................................. 13 2.1 Host Names and Numbers ................................. 13 2.2 Using Domain Name Service .............................. 13 2.3 Applications on Multihomed hosts ....................... 14 2.4 Type-of-Service ........................................ 14 2.5 GENERAL APPLICATION REQUIREMENTS SUMMARY ............... 15 6. SUPPORT SERVICES ............................................ 72 6.1 DOMAIN NAME TRANSLATION ................................. 72 6.1.1 INTRODUCTION ....................................... 72 6.1.2 PROTOCOL WALK-THROUGH ............................. 72 6.1.2.1 Resource Records with Zero TTL ............... 73 6.1.2.2 QCLASS Values ................................ 73 6.1.2.3 Unused Fields ................................ 73 6.1.2.4 Compression .................................. 73 6.1.2.5 Misusing Configuration Info .................. 73 6.1.3 SPECIFIC ISSUES ................................... 74 6.1.3.1 Resolver Implementation ...................... 74 6.1.3.2 Transport Protocols .......................... 75 6.1.3.3 Efficient Resource Usage ..................... 77 6.1.3.4 Multihomed Hosts ............................. 78 6.1.3.5 Extensibility ................................ 79 6.1.3.6 Status of RR Types ........................... 79 6.1.3.7 Robustness ................................... 80 6.1.3.8 Local Host Table ............................. 80 6.1.4 DNS USER INTERFACE ................................ 81 6.1.4.1 DNS Administration ........................... 81 6.1.4.2 DNS User Interface ........................... 81 6.1.4.3 Interface Abbreviation Facilities ............. 82 6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ........... 84 6.2 HOST INITIALIZATION .................................... 87 6.2.1 INTRODUCTION ...................................... 87 6.2.2 REQUIREMENTS ...................................... 87 6.2.2.1 Dynamic Configuration ........................ 87 6.2.2.2 Loading Phase ................................ 89 6.3 REMOTE MANAGEMENT ...................................... 90 6.3.1 INTRODUCTION ...................................... 90 6.3.2 PROTOCOL WALK-THROUGH ............................. 90 6.3.3 MANAGEMENT REQUIREMENTS SUMMARY ................... 92 Multihomed A host is said to be multihomed if it has multiple IP addresses to connected networks. 2.3 Applications on Multihomed hosts When the remote host is multihomed, the name-to-address translation will return a list of alternative IP addresses. As specified in Section 6.1.3.4, this list should be in order of decreasing preference. Application protocol implementations SHOULD be prepared to try multiple addresses from the list until success is obtained. More specific requirements for SMTP are given in Section 5.3.4. When the local host is multihomed, a UDP-based request/response application SHOULD send the response with an IP source address that is the same as the specific destination address of the UDP request datagram. The "specific destination address" is defined in the "IP Addressing" section of the companion RFC [INTRO:1]. | | | | |S| | | | | | |H| |F | | | | |O|M|o | | |S| |U|U|o | | |H| |L|S|t | |M|O| |D|T|n | |U|U|M| | |o | |S|L|A|N|N|t | |T|D|Y|O|O|t FEATURE |SECTION | | | |T|T|e -----------------------------------------------|----------|-|-|-|-|-|-- | | | | | | | User interfaces: | | | | | | | Allow host name to begin with digit |2.1 |x| | | | | Host names of up to 635 characters |2.1 |x| | | | | Host names of up to 255 characters |2.1 | |x| | | | Support dotted-decimal host numbers |2.1 | |x| | | | Check syntactically for dotted-dec first |2.1 | |x| | | | | | | | | | | Map domain names per Section 6.1 |2.2 |x| | | | | Cope with soft DNS errors |2.2 |x| | | | | Reasonable interval between retries |2.2 |x| | | | | Allow for long outages |2.2 |x| | | | | Expect WKS records to be available |2.2 | | | |x| | | | | | | | | Try multiple addr's for remote multihomed host |2.3 | |x| | | | UDP reply src addr is specific dest of request |2.3 | |x| | | | Use same IP addr for related TCP connections |2.3 | |x| | | | Specify appropriate TOS values |2.4 |x| | | | | TOS values configurable |2.4 |x| | | | | Unused TOS bits zero |2.4 |x| | | | | | | | | | | | | | | | | | | On a multihomed server host, the default data transfer port (L-1) MUST be associated with the same local IP address as the corresponding control connection to port L. The use of the different addresses of a multihomed host is discussed below. When it succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of (a) multiple MX records, (b) multihoming, or both. To provide reliable mail transmission, the sender-SMTP MUST be able to try (and retry) each of the addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, a host SHOULD try at least two addresses. (2) Multihomed host -- The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface (see Section 6.1.3.4 below) to have ordered this list by decreasing preference, and SMTP MUST try them in the order presented. DISCUSSION: Although the capability to try multiple alternative addresses is required, there may be circumstances where specific installations want to limit or disable the use of alternative addresses. The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter argument is that it may result in unnecessary resource use. 6.1.3.4 Multihomed Hosts DISCUSSION: The different addresses of a multihomed host generally imply different Internet paths, and some paths may be preferable to others in performance, reliability, or administrative restrictions. There is no general way for the domain system to determine the best path. A recommended approach is to base this decision on local configuration information set by the system administrator. Note that BOOTP is not sufficiently general to specify the configurations of all interfaces of a multihomed host. A multihomed host must either use BOOTP separately for each interface, or configure one interface using BOOTP to perform the loading, and perform the complete initialization from a file later. http://www.ietf.org/rfc/rfc1127.txt 1127 Perspective on the Host Requirements RFCs. R.T. Braden. October 1989. (Format: TXT=3D41267 bytes) (Status: INFORMATIONAL) Require that an application on a multihomed host be able to either specify which local IP address to use for a new TCP connection or UDP request, or else leave the local address "wild" and let the IP layer pick one. Recommend the use of long timeouts and of alternative addresses for multihomed hosts, to obtain robust mail delivery. - IP multihoming models [CL 3.3.4] - The multihoming model [CL 3.3.4] The following requirement is needed: for a multihomed host, a http://www.ietf.org/rfc/rfc1164.txt 1164 Application of the Border Gateway Protocol in the Internet. J.C. Honig, D. Katz, M. Mathis, Y. Rekhter, J.Y. Yu. June 1990. (Format: TXT=3D56278 bytes) (Obsoleted by RFC1268) (Status: HISTORIC) multihomed AS: an AS that has more than one connection to other ASs, but refuses to carry transit traffic. The overall Internet topology may be viewed as an arbitrary interconnection of transit, multihomed, and stub ASs. In order to minimize the impact on the current Internet infrastructure, stub and multihomed ASs need not use BGP. These ASs may run other protocols (e.g., EGP) to exchange reachability information with transit ASs. Transit ASs then tag this information as having been learned via EGP or some other method. The fact that BGP need not run on stub or multihomed ASs has no negative impact on the overall quality of inter-AS routing for traffic not local to the stub or multihomed ASs in question. Of course, BGP may be used for stub and multihomed ASs as well, providing advantage in bandwidth and performance over some of the currently used protocols (such as EGP). In addition, this would result in less need for the use of defaults and in better choices of Inter-AS routes for mulitihomed ASs. 1. A multihomed AS can refuse to act as a transit AS for other ASs. (It does so by not advertising routes to networks other than those directly connected to it.) 2. A multihomed AS can become a transit AS by allowing a certain set of ASs to use it as such. (It does so by advertising routes to networks to this set of ASs.) AS 4 is a good example of a multihomed AS. AS 4 wishes to use AS 3 as is primary path to the backbone, with AS 1 as a backup. Furthermore, AS 4 does not wish to provide any transit service between ASs 1 and 3. Its policy statement could read: http://www.ietf.org/rfc/rfc1268.txt 1268 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. October 1991. (Format: TXT=3D31102 bytes) = (Obsoletes RFC1164) (Obsoleted by RFC1655) (Status: HISTORIC) multihomed AS: an AS that has connections to more than one other AS, but refuses to carry transit traffic. The overall Internet topology may be viewed as an arbitrary interconnection of transit, multihomed, and stub AS's. In order to minimize the impact on the current Internet infrastructure, stub and multihomed AS's need not use BGP. These AS's may run other protocols (e.g., EGP) to exchange reachability information with transit AS's. Transit AS's using BGP will tag this information as having been learned by some method other than BGP. The fact that BGP need not run on stub or multihomed AS's has no negative impact on the overall quality of inter-AS routing for traffic not local to the stub or multihomed AS's in question. However, it is recommended that BGP may be used for stub and multihomed AS's as well, providing an advantage in bandwidth and performance over some of the currently used protocols (such as EGP). In addition, this would result in less need for the use of defaults and in better choices of Inter-AS routes for multihomed AS's. 1. A multihomed AS can refuse to act as a transit AS for other AS's. (It does so by not advertising routes to networks other than those directly connected to it.) 2. A multihomed AS can become a transit AS for a restricted set of adjacent AS's, i.e., some, but not all, AS's can use multihomed AS as a transit AS. (It does so by advertising its routing information to this set of AS's.) http://www.ietf.org/rfc/rfc1383.txt 1383 An Experiment in DNS Based IP Routing. C. Huitema. December 1992. (Format: TXT=3D32680 bytes) (Status: EXPERIMENTAL) The current "textbook" solution to the routing explosion problem is to use "hierarchical routing" based on hierarchical addresses. This is largely documented in routing protocols such as IDRP, and is one of the rationales for deploying the CIDR [3] addressing structure in the Internet. This textbook solution, while often perfectly adequate, as a number of inconveniences, particularly in the presence of "multihomed stubs", e.g., customer networks that are connected to more than one service providers. * allow to support multihomed domains without requiring additional overhead on routing and without requiring hosts to have explicit knowledge of multiple addresses. http://www.ietf.org/rfc/rfc1392.txt 1392 Internet Users' Glossary. G. Malkin, T. LaQuey Parker. January 1993. (Format: TXT=3D104624 bytes) (Obsoleted by RFC1983) (Status: INFORMATIONAL) multihomed host A host which has more than one connection to a network. The host may send and receive data over any of the links but will not route traffic for other nodes. See also: host, router. [Source: MALAMUD] http://www.ietf.org/rfc/rfc1519.txt 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K. Varadhan. = September 1993. (Format: TXT=3D59998 bytes) (Obsoletes RFC1338) (Obsoleted by RFC4632) (Status: PROPOSED STANDARD) Note that the technique here could also apply to class B addresses. However, the limited number of available class B addresses and their usage for multihomed networks suggests that this address space should only be reserved for those large single organizations that warrant this type of address. [2] http://www.ietf.org/rfc/rfc1629.txt 1629 Guidelines for OSI NSAP Allocation in the Internet. R. Colella, R. Callon, E. Gardner, Y. Rekhter. May 1994. (Format: TXT=3D131640 bytes) (Obsoletes RFC1237) (Status: DRAFT STANDARD) For example, suppose that a very large U.S.-wide company "Mega Big International Incorporated" (MBII) has a fully interconnected internal network and is assigned a single AA value under the U.S. GOSIP Version 2 address space. It is likely that outside of the U.S., a single entry may be maintained in routing tables for all U.S. GOSIP addresses. However, within the U.S., every "default-less" provider will need to maintain a separate address entry for MBII. If MBII is in fact an international corporation, then it may be necessary for every "default-less" provider worldwide to maintain a separate entry for MBII (including providers to which MBII is not attached). Clearly this may be acceptable if there are a small number of such multihomed routing domains, but would place an unacceptable load on routers within providers if all organizations were to choose such address assignments. This solution may not scale to internets where there are many hundreds of thousands of multi- homed organizations. To provide routing information aggregation/abstraction we recommend that each provider together with all of its subscriber domains form a Routing Domain Confederation. That, combined with hierarchical address assignment, would provide significant reduction in the volume of routing information that needs to be handled by IDRP. Note that the presence of multihomed subscriber domains would imply that such Confederations will overlap, which is explicitly supported by IDRP. A subscriber RD should use the NSAP prefix assigned to it as its RDI. A multihomed RD should use one of the NSAP prefixes assigned to it as its RDI. If a service provider forms a Routing Domain Confederation with some of its subscribers and the subscribers take their addresses out of the provider, then the NSAP prefix assigned to the provider should be used as the RDCI of the confederation. In this case the provider may use a longer NSAP prefix for its own RDIs. In all other cases a provider should use the address prefix that it uses for assigning addresses to systems within the provider as its RDI. http://www.ietf.org/rfc/rfc1655.txt 1655 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross, Eds.. July 1994. (Format: TXT=3D43664 bytes) (Obsoletes RFC1268) (Obsoleted by RFC1772) (Status: PROPOSED STANDARD) multihomed AS: an AS that has connections to more than one other AS, but refuses to carry transit traffic. The overall Internet topology may be viewed as an arbitrary interconnection of transit, multihomed, and stub AS's. In order to minimize the impact on the current Internet infrastructure, stub and multihomed AS's need not use BGP. These AS's may run other protocols (e.g., EGP) to exchange reachability information with transit AS's. Transit AS's using BGP will tag this information as having been learned by some method other than BGP. The fact that BGP need not run on stub or multihomed AS's has no negative impact on the overall quality of inter-AS routing for traffic that either destined to or originated from the stub or multihomed AS's in question. However, it is recommended that BGP be used for stub and multihomed AS's as well. In these situations, BGP will provide an advantage in bandwidth and performance over some of the currently used protocols (such as EGP). In addition, this would reduce the need for the use of default routes and in better choices of Inter-AS routes for multihomed AS's. 1. A multihomed AS can refuse to act as a transit AS for other AS's. (It does so by only advertising routes to networks internal to the AS.) 2. A multihomed AS can become a transit AS for a restricted set of adjacent AS's, i.e., some, but not all, AS's can use the multihomed AS as a transit AS. (It does so by advertising its routing information to this set of AS's.) http://www.ietf.org/rfc/rfc1679.txt 1679 HPN Working Group Input to the IPng Requirements Solicitation. D. Green, P. Irey, D. Marlow, K. O'Donoghue. August 1994. (Format: TXT=3D22974 bytes) (Status: INFORMATIONAL) 3) The IPng protocols need to support hosts that may be multihomed. Multihomed in this context implies that a single host may support multiple different subnetwork technologies. Multihomed hosts must have the capability to steer the traffic to selected subnetworks. http://www.ietf.org/rfc/rfc1716.txt 1716 Towards Requirements for IP Routers. P. Almquist, F. Kastenholz. November 1994. (Format: TXT=3D432330 bytes) (Obsoleted by RFC1812) (Status: INFORMATIONAL) (2) If a (multihomed) host acts as a router, it must implement ALL the relevant router requirements contained in this document. Multihoming is possible on one wide-area network, but may present routing problems if the interfaces are geographically or topologically separated. Multihoming on two (or more) wide-area networks is a problem due to the confusion of addresses. Section 4.2.3.7: If an application on a multihomed host does not specify the local IP address when actively opening a TCP connection, then the TCP MUST ask the IP layer to select a local IP address before sending the (first) SYN. See the function GET_SRCADDR() in Section 3.4. http://www.ietf.org/rfc/rfc1772.txt 1772 Application of the Border Gateway Protocol in the Internet. Y. Rekhter, P. Gross. March 1995. (Format: TXT=3D43916 bytes) = (Obsoletes RFC1655) (Status: DRAFT STANDARD) multihomed AS: an AS that has connections to more than one other AS, but refuses to carry transit traffic. The overall Internet topology may be viewed as an arbitrary interconnection of transit, multihomed, and stub AS's. In order to minimize the impact on the current Internet infrastructure, stub and multihomed AS's need not use BGP. These AS's may run other protocols (e.g., EGP) to exchange reachability information with transit AS's. Transit AS's using BGP will tag this information as having been learned by some method other than BGP. The fact that BGP need not run on stub or multihomed AS's has no negative impact on the overall quality of inter-AS routing for traffic that either destined to or originated from the stub or multihomed AS's in question. However, it is recommended that BGP be used for stub and multihomed AS's as well. In these situations, BGP will provide an advantage in bandwidth and performance over some of the currently used protocols (such as EGP). In addition, this would reduce the need for the use of default routes and in better choices of Inter-AS routes for multihomed AS's. 1. A multihomed AS can refuse to act as a transit AS for other AS's. (It does so by only advertising routes to destinations internal to the AS.) 2. A multihomed AS can become a transit AS for a restricted set of adjacent AS's, i.e., some, but not all, AS's can use the multihomed AS as a transit AS. (It does so by advertising its routing information to this set of AS's.) http://www.ietf.org/rfc/rfc1786.txt 1786 Representation of IP Routing Policies in a Routing Registry (ripe-81++). T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, M. Terpstra, J. Yu. March 1995. (Format: TXT=3D133643 bytes) (Status: INFORMATIONAL) remarks: Multihomed AS talking to AS1755 and AS786 remarks: Will soon connect to AS1104 also. remarks: Multihomed AS talking to AS1755 and AS786 remarks: Will soon connect to AS1104 also. http://www.ietf.org/rfc/rfc1812.txt 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995. (Format: TXT=3D415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated = by RFC2644) (Status: PROPOSED STANDARD) (2) If a (multihomed) host acts as a router, it is subject to the requirements for routers contained in this document. Multihoming is possible on one wide-area network, but may present routing problems if the interfaces are geographically or topologically separated. Multihoming on two (or more) wide-area networks is a problem due to the confusion of addresses. TCP Multihoming: If an application on a multihomed host does not specify the local IP address when actively opening a TCP connection, then the TCP MUST ask the IP layer to select a local IP address before sending the (first) SYN. See the function GET_SRCADDR() in Section 3.4. http://www.ietf.org/rfc/rfc1932.txt 1932 IP over ATM: A Framework Document. R. Cole, D. Shur, C. Villamizar. April 1996. (Format: TXT=3D68031 bytes) (Status: INFORMATIONAL) LANs are used for network interconnections at the the major Internet traffic interconnect sites. Such LANs have multiple administrative authorities, currently exclusively support routers providing transit to multihomed internets, currently rely on PVCs and static address resolution, and rely heavily on IP routing. Such a configuration differs from the typical LANs used to interconnect computers in corporate or campus environments, and emphasizes the point that prior characterization of LANs do not necessarily hold. Similarly, WANs such as those under consideration by numerous large IP providers, do not conform to prior characterizations of ATM WANs in that they have a single administrative authority and a small number of nodes aggregating large flows of traffic onto single PVCs and rely on IP routers to avoid forming congestion bottlenecks within ATM. o Presence of routers providing transit to multihomed internets. In the Peer Model no provision is made for selection of primary path and use of alternate paths in the event of primary path failure in reaching multihomed non-ATM destinations. This will limit the topologies for which the peer model alone is applicable to only those topologies in which non-ATM networks are singly homed, or where loss of backup connectivity is not an issue. The Peer Model may be used to avoid the need for an address resolution protocol and in a proxy- ARP mode for stub networks, in conjunction with other mechanisms suitable to handle multihomed destinations. http://www.ietf.org/rfc/rfc1970.txt 1970 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. August 1996. (Format: TXT=3D197632 bytes) (Obsoleted by RFC2461) (Status: PROPOSED STANDARD) 10. PROTOCOL CONSTANTS...................................... 72 11. SECURITY CONSIDERATIONS................................. 73 REFERENCES................................................... 75 AUTHORS' ADDRESSES........................................... 76 APPENDIX A: MULTIHOMED HOSTS................................. 77 APPENDIX B: FUTURE EXTENSIONS................................ 78 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE......... 78 APPENDIX D: IMPLEMENTATION ISSUES............................ 80 Appendix D.1: Reachability confirmations.................. 80 Prefix Information These options specify the prefixes that are on-link and/or are used for address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on-link destinations for the links to which they attach. If complete information is lacking, a multihomed host may not be This model is only concerned with the aspects of host behavior directly related to Neighbor Discovery. In particular, it does not concern itself with such issues as source address selection or the selecting of an outgoing interface on a multihomed host. Routers and multihomed hosts have multiple interfaces. The remainder of this document assumes that all sent and received Neighbor Discovery messages refer to the interface of appropriate context. For example, when responding to a Router Solicitation, the corresponding Router Advertisement is sent out the interface on which the solicitation was received. APPENDIX A: MULTIHOMED HOSTS There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work on multihomed hosts and to report their experiences. If a multihomed host receives Router Advertisements on all of its interfaces, it will (probably) have learned on-link prefixes for the addresses residing on each link. When a packet must be sent through a router, however, selecting the "wrong" router can result in a suboptimal or non-functioning path. There are number of issues to consider: 1) In order for a router to send a redirect, it must determine that the packet it is forwarding originates from a neighbor. The standard test for this case is to compare the source address of the packet to the list of on-link prefixes associated with the interface on which the packet was received. If the originating host is multihomed, however, the source address it uses may belong to an interface other than the interface from which it was sent. In such cases, a router will not send redirects, and suboptimal routing is likely. In order to be redirected, the sending host must always send packets out the interface corresponding to the outgoing packet's source address. Note that this issue never arises with non-multihomed hosts; they only have one interface. 2) If the selected first-hop router does not have a route at all for the destination, it will be unable to deliver the packet. However, the destination may be reachable through a router on one of the other interfaces. Neighbor Discovery does not address this scenario; it does not arise in the non-multihomed case. 3) Even if the first-hop router does have a route for a destination, there may be a better route via another interface. No mechanism exists for the multihomed host to detect this situation. If a multihomed host fails to receive Router Advertisements on one or more of its interfaces, it will not know (in the absence of configured information) which destinations are on-link on the affected interface(s). This leads to a number of problems: 1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. Under similar conditions in the non-multihomed host case, a node treats all destinations as residing on-link, and communication proceeds. In the multihomed case, however, additional information is needed to select the proper outgoing interface. Alternatively, a node could attempt to perform address resolution on all interfaces, a step involving significant complexity that is not present in the non- multihomed host case. 2) If Router Advertisements are received on some, but not all interfaces, a multihomed host could choose to only send packets out on the interfaces on which it has received Router Advertisements. A key assumption made here, however, is that routers on those other interfaces will be able to route packets to the ultimate destination, even when those destinations reside on the subnet to which the sender connects, but has no on-link prefix information. Should the assumption be false, communication would fail. Even if the assumption holds, packets will traverse a sub-optimal path. http://www.ietf.org/rfc/rfc1971.txt 1971 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. August 1996. (Format: TXT=3D56890 bytes) (Obsoleted by RFC2462) (Status: PROPOSED STANDARD) Autoconfiguration is performed on a per-interface basis on multicast-capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. Autoconfiguration applies primarily to hosts, with two exceptions. Routers are expected to generate a link-local address using the procedure outlined below. In addition, routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface. http://www.ietf.org/rfc/rfc1983.txt 1983 Internet Users' Glossary. G. Malkin, Ed.. August 1996. (Format: TXT=3D123008 bytes) (Obsoletes RFC1392) (Also FYI0018) (Status: INFORMATIONAL) multihomed host A host which has more than one connection to a network. The host may send and receive data over any of the links but will not route traffic for other nodes. See also: host, router. [Source: MALAMUD] http://www.ietf.org/rfc/rfc1996.txt 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY). P. Vixie. August 1996. (Format: TXT=3D15247 bytes) (Updates = RFC1035) (Status: PROPOSED STANDARD) Note: This implies that slaves of a multihomed master must either know their master by the "closest" of the master's interface addresses, or must know all of the master's interface addresses. Otherwise, a valid NOTIFY request might come from an address that is not on the slave's state list of masters for the zone, which would be an error. http://www.ietf.org/rfc/rfc2071.txt 2071 Network Renumbering Overview: Why would I want it and what is it anyway?. P. Ferguson, H. Berkowitz. January 1997. (Format: = TXT=3D33218 bytes) (Status: INFORMATIONAL) However, the recent popularity in obtaining Internet connectivity has made these types of connectivity dependencies unpredictable, and conventional wisdom in the Internet community dictates that the various address allocation registries, such as the InterNIC, as well as the ISP's, become more prudent in their address allocation strategies. In that vein, the InterNIC has defined address allocation policies [3] wherein the majority of address allocations for end-user networks are accommodated by their upstream ISP, except in cases where dual- or multihoming and very large blocks of addresses are required. With this allocation policy becoming standard current practice, it presents unique problems regarding the portability of addresses from one provider to another. http://www.ietf.org/rfc/rfc2205.txt 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification. R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September 1997. (Format: TXT=3D223974 bytes) (Updated by RFC2750, RFC3936, RFC4495, RFC5946) (Status: PROPOSED STANDARD) 1. Introduction ................................................... 4 1.1 Data Flows ................................................. 7 1.2 Reservation Model .......................................... 8 1.3 Reservation Styles .........................................11 1.4 Examples of Styles .........................................14 2. RSVP Protocol Mechanisms .......................................19 2.1 RSVP Messages ..............................................19 2.2 Merging Flowspecs ..........................................21 2.3 Soft State .................................................22 2.4 Teardown ...................................................24 2.5 Errors .....................................................25 2.6 Confirmation ...............................................27 2.7 Policy Control .............................................27 2.8 Security ...................................................28 2.9 Non-RSVP Clouds ............................................29 2.10 Host Model ................................................30 3. RSVP Functional Specification ..................................32 3.1 RSVP Message Formats .......................................32 3.2 Port Usage .................................................47 3.3 Sending RSVP Messages ......................................48 3.4 Avoiding RSVP Message Loops ................................50 3.5 Blockade State .............................................54 3.6 Local Repair ...............................................56 3.7 Time Parameters ............................................57 3.8 Traffic Policing and Non-Integrated Service Hops ...........58 3.9 Multihomed Hosts ...........................................59 3.10 Future Compatibility ......................................61 3.11 RSVP Interfaces ...........................................63 4. Acknowledgments ................................................76 APPENDIX A. Object Definitions ....................................77 APPENDIX B. Error Codes and Values ................................92 APPENDIX C. UDP Encapsulation .....................................98 APPENDIX D. Glossary .............................................102 REFERENCES .......................................................111 SECURITY CONSIDERATIONS ..........................................111 AUTHORS' ADDRESSES ...............................................112 3.9 Multihomed Hosts Accommodating multihomed hosts requires some special rules in RSVP. We use the term `multihomed host' to cover both hosts (end systems) with more than one network interface and routers that are supporting local application programs. An application executing on a multihomed host may explicitly specify which interface any given flow will use for sending and/or for receiving data packets, to override the system-specified default interface. The RSVP process must be aware of the default, and if an application sets a specific interface, it must also pass that information to RSVP. This is the address of the interface from which the data will be sent. If it is omitted, a default interface will be used. This parameter is needed only on a multihomed sender host. The optional `receiver_address' parameter may be used by a receiver on a multihomed host (or router); it is the IP address of one of the node's interfaces. The CONF_flag should be set on if a reservation confirmation is desired, off otherwise. The `Policy_data' parameter specifies policy data for the receiver, while the `style' parameter indicates the reservation style. The rest of the parameters depend upon the style; generally these will be appropriate flowspecs and filter specs. http://www.ietf.org/rfc/rfc2260.txt 2260 Scalable Support for Multi-homed Multi-provider Connectivity. T. Bates, Y. Rekhter. January 1998. (Format: TXT=3D28085 bytes) = (Status: INFORMATIONAL) RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 The approach described in this document assumes that addresses that an enterprise would use are allocated based on the "address lending" policy. Consequently, whenever an enterprise changes its ISP, the enterprise would need to renumber part of its network that was numbered out of the address block that the ISP allocated to the enterprise. However, these issues are not specific to multihoming and should be considered accepted practice in todays internet. The approach described in this document effectively eliminates any distinction between single-home and multi-homed enterprise with respect to the impact of changing ISPs on renumbering. RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 RFC 2260 Multihoming January 1998 http://www.ietf.org/rfc/rfc2320.txt 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB). M. Greene, J. Luciani, K. White, T. Kuo. April 1998. (Format: TXT=3D102116 bytes) (Status: PROPOSED = STANDARD) On a host that supports multiple ATMARP Servers where the local IP address being associated with each ATMARP Server is the same (for example a non-multihomed host), the ATM Address (ipoaArpSrvrAddr) uniquely identifies a particular ATMARP Server. On a host supporting multiple ATMARP Servers having a single ATM Interface with a single ATM Address, the ipAdEntAddr MUST be used to uniquely identify an entry in the ipoaArpSrvrTable. http://www.ietf.org/rfc/rfc2374.txt 2374 An IPv6 Aggregatable Global Unicast Address Format. R. Hinden, M. O'Dell, S. Deering. July 1998. (Format: TXT=3D25068 bytes) = (Obsoletes RFC2073) (Obsoleted by RFC3587) (Status: HISTORIC) addressing independence from long-haul transit providers. They will be able to change long-haul providers without having to renumber their organization. They can also be multihomed via the exchange to more than one long-haul provider without having to have address prefixes from each long-haul provider. Note that the mechanisms used for this type of provider selection and portability are not discussed in the document. http://www.ietf.org/rfc/rfc2401.txt 2401 Security Architecture for the Internet Protocol. S. Kent, R. Atkinson. November 1998. (Format: TXT=3D168162 bytes) (Obsoletes RFC1825) (Obsoleted by RFC4301) (Updated by RFC3168) (Status: PROPOSED STANDARD) - Source IP Address(es) (IPv4 or IPv6): this may be a single IP address (unicast, anycast, broadcast (IPv4 only), or multicast group), range of addresses (high and low values inclusive), address + mask, or a wildcard address. The last three are used to support more than one source system sharing the same SA (e.g., behind a security gateway or in a multihomed host). [REQUIRED for all implementations] http://www.ietf.org/rfc/rfc2439.txt 2439 BGP Route Flap Damping. C. Villamizar, R. Chandra, R. Govindan. November 1998. (Format: TXT=3D86376 bytes) (Status: PROPOSED = STANDARD) Parameter selection can also be based on prefix length. The rationale is that longer prefixes tend to reach less end systems and are less important and these less important prefixes can be damped more aggressively. This technique is in fairly widespread use. Small sites or those with dense address allocation who are multihomed are often reachable by long prefixes which are not easily aggregated. These sites tend to dispute the choice of prefix length for parameter selection. Advocates of the technique point out that it encourages better aggregation. http://www.ietf.org/rfc/rfc2450.txt 2450 Proposed TLA and NLA Assignment Rule. R. Hinden. December 1998. (Format: TXT=3D24486 bytes) (Status: INFORMATIONAL) - Only assign top level prefixes to transit providers, not to leaf sites even if they are multiply homed. The aggregation address format is designed to have a clear separation between transit providers and leaf sites. Sites which wish to be multihomed to multiple transit providers have in IPv6 a number of alternatives to having a top level prefix. 2) Must have a verifiable track record of providing Internet transit to other organizations. Sub-TLA and/or TLA ID's must not be assigned to organizations that are only providing leaf service even if multihomed. http://www.ietf.org/rfc/rfc2461.txt 2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998. (Format: TXT=3D222516 bytes) (Obsoletes RFC1970) (Obsoleted by RFC4861) (Updated by RFC4311) (Status: DRAFT STANDARD) References................................................... 80 Authors' Addresses........................................... 81 Appendix A: Multihomed Hosts................................. 82 Appendix B: Future Extensions................................ 84 Appendix C: State Machine for the Reachability State......... 85 Appendix D: Summary of ISROUTER Rules........................ 88 Appendix E: Implementation Issues............................ 89 Appendix E.1: Reachability confirmations................. 89 Appendix F: Changes since RFC 1970........................... 91 Full Copyright Statement..................................... 93 Prefix Information These options specify the prefixes that are on-link and/or are used for address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on- link destinations for the links to which they attach. If complete information is lacking, a multihomed host may not be able to choose the correct outgoing interface when sending traffic to its neighbors. This model is only concerned with the aspects of host behavior directly related to Neighbor Discovery. In particular, it does not concern itself with such issues as source address selection or the selecting of an outgoing interface on a multihomed host. Routers and multihomed hosts have multiple interfaces. The remainder of this document assumes that all sent and received Neighbor Discovery messages refer to the interface of appropriate context. For example, when responding to a Router Solicitation, the corresponding Router Advertisement is sent out the interface on which the solicitation was received. APPENDIX A: MULTIHOMED HOSTS There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work on multihomed hosts and to report their experiences. If a multihomed host receives Router Advertisements on all of its interfaces, it will (probably) have learned on-link prefixes for the addresses residing on each link. When a packet must be sent through a router, however, selecting the "wrong" router can result in a suboptimal or non-functioning path. There are number of issues to consider: 1) In order for a router to send a redirect, it must determine that the packet it is forwarding originates from a neighbor. The standard test for this case is to compare the source address of the packet to the list of on-link prefixes associated with the interface on which the packet was received. If the originating host is multihomed, however, the source address it uses may belong to an interface other than the interface from which it was sent. In such cases, a router will not send redirects, and suboptimal routing is likely. In order to be redirected, the sending host must always send packets out the interface corresponding to the outgoing packet's source address. Note that this issue never arises with non-multihomed hosts; they only have one interface. 2) If the selected first-hop router does not have a route at all for the destination, it will be unable to deliver the packet. However, the destination may be reachable through a router on one of the other interfaces. Neighbor Discovery does not address this scenario; it does not arise in the non-multihomed case. 3) Even if the first-hop router does have a route for a destination, there may be a better route via another interface. No mechanism exists for the multihomed host to detect this situation. If a multihomed host fails to receive Router Advertisements on one or more of its interfaces, it will not know (in the absence of configured information) which destinations are on-link on the affected interface(s). This leads to a number of problems: 1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. Under similar conditions in the non-multihomed host case, a node treats all destinations as residing on-link, and communication proceeds. In the multihomed case, however, additional information is needed to select the proper outgoing interface. Alternatively, a node could attempt to perform address resolution on all interfaces, a step involving significant complexity that is not present in the non-multihomed host case. 2) If Router Advertisements are received on some, but not all interfaces, a multihomed host could choose to only send packets out on the interfaces on which it has received Router Advertisements. A key assumption made here, however, is that routers on those other interfaces will be able to route packets to the ultimate destination, even when those destinations reside on the subnet to which the sender connects, but has no on-link prefix information. Should the assumption be FALSE, communication would fail. Even if the assumption holds, packets will traverse a sub-optimal path. http://www.ietf.org/rfc/rfc2462.txt 2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT=3D61210 bytes) (Obsoletes RFC1971) (Obsoleted by RFC4862) (Status: DRAFT STANDARD) Autoconfiguration is performed on a per-interface basis on multicast-capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. Autoconfiguration applies primarily to hosts, with two exceptions. Routers are expected to generate a link-local address using the procedure outlined below. In addition, routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface. http://www.ietf.org/rfc/rfc2614.txt 2614 An API for Service Location. J. Kempf, E. Guttman. June 1999. (Format: TXT=3D164002 bytes) (Status: INFORMATIONAL) 1. Introduction 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . 4 2. File Formats 7 2.1. Configuration File Format . . . . . . . . . . . . . . 8 2.1.1. DA configuration . . . . . . . . . . . . . . 9 2.1.2. Static Scope Configuration . . . . . . . . . . 9 2.1.3. Tracing and Logging . . . . . . . . . . . . . 11 2.1.4. Serialized Proxy Registrations . . . . . . . . 11 2.1.5. Network Configuration Properties . . . . . . . 12 2.1.6. SA Configuration . . . . . . . . . . . . . . . 14 2.1.7. UA Configuration . . . . . . . . . . . . . . . 14 2.1.8. Security . . . . . . . . . . . . . . . . . . 15 2.2. Multihomed Machines. . . . . . . . . . . . . . . . . . 16 2.3. Serialized Registration File . . . . . . . . . . . . . 16 2.2. Multihomed Machines On multihomed machines, the bandwidth and latency characteristics on different network interfaces may differ considerably, to the point where different configuration properties are necessary to achieve optimal performance. The net.slp.interfaces property indicates which network interfaces are SLP enabled. An API library implementation may support configuration customization on a per network interface basis by allowing the interface IP address to be appended to the property name. In that case, the values of the property are only used for that particular interface, the generic property (or defaults if no generic property is set) applies to all others. http://www.ietf.org/rfc/rfc2663.txt 2663 IP Network Address Translator (NAT) Terminology and Considerations. P. Srisuresh, M. Holdrege. August 1999. (Format: TXT=3D72265 bytes) (Status: INFORMATIONAL) 4.4. Multihomed NAT In order for a private network to ensure that connectivity with external networks is retained even as one of the NAT links fail, it is often desirable to multihome the private network to same or multiple service providers with multiple connections from the private domain, be it from same or different NAT boxes. http://www.ietf.org/rfc/rfc2694.txt 2694 DNS extensions to Network Address Translators (DNS_ALG). P. Srisuresh, G. Tsirtsis, P. Akkiraju, A. Heffernan. September 1999. (Format: TXT=3D67720 bytes) (Status: INFORMATIONAL) * private.com is not multihomed and all traffic to the external space transits a single NAT. http://www.ietf.org/rfc/rfc2725.txt 2725 Routing Policy System Security. C. Villamizar, C. Alaettinoglu, D. Meyer, S. Murphy. December 1999. (Format: TXT=3D101649 bytes) (Updated by RFC4012) (Status: PROPOSED STANDARD) 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Background . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Implicit Policy Assumptions . . . . . . . . . . . . . . . . 5 4 Scope of Security Coverage . . . . . . . . . . . . . . . . 5 5 Organization of this Document . . . . . . . . . . . . . . 6 6 Goals and Requirements . . . . . . . . . . . . . . . . . . 6 7 Data Representation . . . . . . . . . . . . . . . . . . . . 10 8 Authentication Model . . . . . . . . . . . . . . . . . . . 10 9 Authorization Model . . . . . . . . . . . . . . . . . . . . 12 9.1 Maintainer Objects . . . . . . . . . . . . . . . . . . 12 9.2 as-block and aut-num objects . . . . . . . . . . . . . 13 9.3 inetnum objects . . . . . . . . . . . . . . . . . . . 13 9.4 route objects . . . . . . . . . . . . . . . . . . . . 14 9.5 reclaim and no-reclaim attributes . . . . . . . . . . 14 9.6 Other Objects . . . . . . . . . . . . . . . . . . . . 15 9.7 Objects with AS Hierarchical Names . . . . . . . . . . 16 9.8 Query Processing . . . . . . . . . . . . . . . . . . . 16 9.9 Adding to the Database . . . . . . . . . . . . . . . . 17 9.10 Modifying or Deleting Database Objects . . . . . . . . 19 10 Data Format Summaries . . . . . . . . . . . . . . . . . . 20 10.1 Changes to the RIPE/RPSL Schema . . . . . . . . . . . 20 Appendicies A Core and Non-Core Functionality . . . . . . . . . . . . . . 23 B Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 C Technical Discussion . . . . . . . . . . . . . . . . . . . 26 C.1 Relaxing requirements for ease of registry . . . . . 27 C.2 The address lending issue . . . . . . . . . . . . . . 28 C.3 Dealing with non-conformant or questionable older data . . . . . . . . . . . . . . . . . . . . . . . . . 29 D Common Operational Cases . . . . . . . . . . . . . . . . . 30 D.1 simple hierarchical address allocation and route allocation . . . . . . . . . . . . . . . . . . . . . . 31 D.2 aggregation and multihomed more specific routes . . . 32 D.3 provider independent addresses and multiple origin AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32 D.4 change in Internet service provider . . . . . . . . . 32 D.5 renumbering grace periods . . . . . . . . . . . . . . 32 E Deployment Considerations . . . . . . . . . . . . . . . . . 33 F Route Object Authorization Pseudocode . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 Intellectual Property Notice . . . . . . . . . . . . . . . . . 38 References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Security Considerations . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40 Full Copyright Statement . . . . . . . . . . . . . . . . . . 41 Autonomous system numbers can be delegated in blocks and subdelegated as needed and then individual AS numbers assigned. Address allocation is a simple numeric hierarchy. Route allocation is somewhat more complicated. The key attributes in a route object (key with regard to making it unique) contain both an address prefix and an AS number, known as the origin AS. The addition of a route object must be validated against the authorization criteria for both the AS and the address prefix. Route objects may exist for the same prefix with multiple origin AS values due to a common multihoming practice that does not require a unique origin AS. There is often no correlation between the origin AS of a prefix and the origin AS of overlapping more specific prefixes. o aggregation and multihomed more specific routes D.2 aggregation and multihomed more specific routes Provider independent addresses and multihoming arrangement using multiple origin AS present a similar problem to multihoming. The maintainer of the address space and the maintainer of the AS is not the same. Permission can be granted using mnt-routes or multiple signatures can appear on the submission. A change in Internet service providers is similar to multihoming. A minor difference is that the AS for the more specific route will be the AS of the new provider rather than the AS of the multihomed customer. Permission can be granted using mnt-routes or multiple signatures can appear on the submission. http://www.ietf.org/rfc/rfc2764.txt 2764 A Framework for IP Based Virtual Private Networks. B. Gleeson, A. Lin, J. Heinanen, G. Armitage, A. Malis. February 2000. (Format: TXT=3D163215 bytes) (Status: INFORMATIONAL) 1.0 Introduction ................................................ 4 2.0 VPN Application and Implementation Requirements ............. 5 2.1 General VPN Requirements .................................... 5 2.1.1 Opaque Packet Transport: ................................. 6 2.1.2 Data Security ............................................. 7 2.1.3 Quality of Service Guarantees ............................. 7 2.1.4 Tunneling Mechanism ....................................... 8 2.2 CPE and Network Based VPNs .................................. 8 2.3 VPNs and Extranets .......................................... 9 3.0 VPN Tunneling ............................................... 10 3.1 Tunneling Protocol Requirements for VPNs .................... 11 3.1.1 Multiplexing .............................................. 11 3.1.2 Signalling Protocol ....................................... 12 3.1.3 Data Security ............................................. 13 3.1.4 Multiprotocol Transport ................................... 14 3.1.5 Frame Sequencing .......................................... 14 3.1.6 Tunnel Maintenance ........................................ 15 3.1.7 Large MTUs ................................................ 16 3.1.8 Minimization of Tunnel Overhead ........................... 16 3.1.9 Flow and congestion control ............................... 17 3.1.10 QoS / Traffic Management ................................. 17 3.2 Recommendations ............................................. 18 4.0 VPN Types: Virtual Leased Lines ............................ 18 5.0 VPN Types: Virtual Private Routed Networks ................. 20 5.1 VPRN Characteristics ........................................ 20 5.1.1 Topology .................................................. 23 5.1.2 Addressing ................................................ 24 5.1.3 Forwarding ................................................ 24 5.1.4 Multiple concurrent VPRN connectivity ..................... 24 5.2 VPRN Related Work ........................................... 24 5.3 VPRN Generic Requirements ................................... 25 5.3.1 VPN Identifier ............................................ 26 5.3.2 VPN Membership Information Configuration .................. 27 5.3.2.1 Directory Lookup ........................................ 27 5.3.2.2 Explicit Management Configuration ....................... 28 5.3.2.3 Piggybacking in Routing Protocols ....................... 28 5.3.3 Stub Link Reachability Information ........................ 30 5.3.3.1 Stub Link Connectivity Scenarios ........................ 30 5.3.3.1.1 Dual VPRN and Internet Connectivity ................... 30 5.3.3.1.2 VPRN Connectivity Only ................................ 30 5.3.3.1.3 Multihomed Connectivity ............................... 31 5.3.3.1.4 Backdoor Links ........................................ 31 5.3.3.1 Routing Protocol Instance ............................... 31 5.3.3.2 Configuration ........................................... 33 5.3.3.3 ISP Administered Addresses .............................. 33 5.3.3.4 MPLS Label Distribution Protocol ........................ 33 5.3.4 Intra-VPN Reachability Information ........................ 34 5.3.4.1 Directory Lookup ........................................ 34 5.3.4.2 Explicit Configuration .................................. 34 5.3.4.3 Local Intra-VPRN Routing Instantiations ................. 34 5.3.4.4 Link Reachability Protocol .............................. 35 5.3.4.5 Piggybacking in IP Backbone Routing Protocols ........... 36 5.3.5 Tunneling Mechanisms ...................................... 36 5.4 Multihomed Stub Routers ..................................... 37 5.5 Multicast Support ........................................... 38 5.5.1 Edge Replication .......................................... 38 5.5.2 Native Multicast Support .................................. 39 5.6 Recommendations ............................................. 40 6.0 VPN Types: Virtual Private Dial Networks ................... 41 6.1 L2TP protocol characteristics ............................... 41 6.1.1 Multiplexing .............................................. 41 6.1.2 Signalling ................................................ 42 6.1.3 Data Security ............................................. 42 6.1.4 Multiprotocol Transport ................................... 42 6.1.5 Sequencing ................................................ 42 6.1.6 Tunnel Maintenance ........................................ 43 6.1.7 Large MTUs ................................................ 43 6.1.8 Tunnel Overhead ........................................... 43 6.1.9 Flow and Congestion Control ............................... 43 6.1.10 QoS / Traffic Management ................................. 43 6.1.11 Miscellaneous ............................................ 44 6.2 Compulsory Tunneling ........................................ 44 6.3 Voluntary Tunnels ........................................... 46 6.3.1 Issues with Use of L2TP for Voluntary Tunnels ............. 46 6.3.2 Issues with Use of IPSec for Voluntary Tunnels ............ 48 6.4 Networked Host Support ...................................... 49 6.4.1 Extension of PPP to Hosts Through L2TP .................... 49 6.4.2 Extension of PPP Directly to Hosts: ...................... 49 6.4.3 Use of IPSec .............................................. 50 6.5 Recommendations ............................................. 50 7.0 VPN Types: Virtual Private LAN Segment ..................... 50 7.1 VPLS Requirements ........................................... 51 7.1.1 Tunneling Protocols ....................................... 51 7.1.2 Multicast and Broadcast Support ........................... 52 7.1.3 VPLS Membership Configuration and Topology ................ 52 7.1.4 CPE Stub Node Types ....................................... 52 7.1.5 Stub Link Packet Encapsulation ............................ 53 7.1.5.1 Bridge CPE .............................................. 53 7.1.5.2 Router CPE .............................................. 53 7.1.6 CPE Addressing and Address Resolution ..................... 53 7.1.6.1 Bridge CPE .............................................. 53 7.1.6.2 Router CPE .............................................. 54 7.1.7 VPLS Edge Node Forwarding and Reachability Mechanisms ..... 54 7.1.7.1 Bridge CPE .............................................. 54 An example VPRN is illustrated in the following diagram, which shows 3 ISP edge routers connected via a full mesh of IP tunnels, used to interconnect 4 CPE routers. One of the CPE routers is multihomed to the ISP network. In the multihomed case, all stub links may be active, or, as shown, there may be one primary and one or more backup links to be used in case of failure of the primary. The term ' backdoor' link is used to refer to a link between two customer sites 5.3.3.1.3 Multihomed Connectivity The CPE router is multihomed to the ISP network, which provides VPRN connectivity. 5.4 Multihomed Stub Routers The discussion thus far has implicitly assumed that stub routers are connected to one and only one VPRN edge router. In general, this restriction should be capable of being relaxed without any change to VPRN operation, given general market interest in multihoming for reliability and other reasons. In particular, in cases where the stub router supports multiple redundant links, with only one operational at any given time, with the links connected either to the same VPRN edge router, or to two or more different VPRN edge routers, then the stub link reachability mechanisms will both discover the loss of an active link, and the activation of a backup link. In the former situation, the previously connected VPRN edge router will cease advertising reachability to the stub node, while the VPRN edge router with the now active link will begin advertising reachability, hence restoring connectivity. http://www.ietf.org/rfc/rfc2775.txt 2775 Internet Transparency. B. Carpenter. February 2000. (Format: TXT=3D42956 bytes) (Status: INFORMATIONAL) Many of the inventions described in the previous section lead to the datagram traffic between two hosts being directly or indirectly mediated by at least one other host. For example a client may depend on a DHCP server, a server may depend on a NAT, and any host may depend on a firewall. This violates the fate-sharing principle of [Saltzer] and introduces single points of failure. Worse, most of these points of failure require configuration data, yet another source of operational risk. The original notion that datagrams would find their way around failures, especially around failed routers, has been lost; indeed the overloading of border routers with additional functions has turned them into critical rather than redundant components, even for multihomed sites. http://www.ietf.org/rfc/rfc2821.txt 2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001. (Format: TXT=3D192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869, STD0010) (Obsoleted by RFC5321) (Updated by RFC5336) (Status: PROPOSED STANDARD) When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses. Two types of information is used to rank the host addresses: multiple MX records, and multihomed hosts. The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and SMTP MUST try them in the order presented. Although the capability to try multiple alternative addresses is required, specific installations may want to limit or disable the use of alternative addresses. The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter- argument is that it may result in unnecessary resource use. Note that resource use is also strongly determined by the sending strategy discussed in section 4.5.4.1. http://www.ietf.org/rfc/rfc2874.txt 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering. M. Crawford, C. Huitema. July 2000. (Format: TXT=3D44204= bytes) (Updates RFC1886) (Updated by RFC3152, RFC3226, RFC3363, RFC3364) (Status: EXPERIMENTAL) For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. This memo proposes a replacement for the specification in RFC 1886 [AAAA] and a departure from current implementation practices. The changes are designed to facilitate network renumbering and multihoming. Domains employing the A6 record for IPv6 addresses can insert automatically-generated AAAA records in zone files to ease transition. It is expected that after a reasonable period, RFC 1886 will become Historic. http://www.ietf.org/rfc/rfc3056.txt 3056 Connection of IPv6 Domains via IPv4 Clouds. B. Carpenter, K. Moore. February 2001. (Format: TXT=3D54902 bytes) (Status: PROPOSED STANDARD) 1. Introduction................................................. 2 1.1. Terminology................................................ 4 2. IPv6 Prefix Allocation....................................... 5 2.1 Address Selection........................................... 6 3. Encapsulation in IPv4........................................ 6 3.1. Link-Local Address and NUD................................. 7 4. Maximum Transmission Unit.................................... 7 5. Unicast scenarios, scaling, and transition to normal prefixes 8 5.1 Simple scenario - all sites work the same................... 8 5.2 Mixed scenario with relay to native IPv6................... 9 5.2.1 Variant scenario with ISP relay.......................... 12 5.2.2 Summary of relay router configuration.................... 12 5.2.2.1. BGP4+ not used........................................ 12 5.2.2.2. BGP4+ used............................................ 12 5.2.2.3. Relay router scaling.................................. 13 5.2.3 Unwilling to relay....................................... 13 5.3 Sending and decapsulation rules............................ 13 5.4 Variant scenario with tunnel to IPv6 space................. 14 5.5 Fragmented Scenarios....................................... 14 5.6 Multihoming................................................ 16 5.7 Transition Considerations.................................. 16 5.8 Coexistence with firewall, NAT or RSIP..................... 16 5.9 Usage within Intranets..................................... 17 5.10 Summary of impact on routing.............................. 18 5.11. Routing loop prevention.................................. 18 6. Multicast and Anycast....................................... 19 7. ICMP messages............................................... 19 8. IANA Considerations......................................... 19 9. Security Considerations..................................... 19 Acknowledgements............................................... 20 References..................................................... 20 Authors' Addresses............................................. 22 Intellectual Property.......................................... 22 Full Copyright Statement....................................... 23 5.6 Multihoming Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by using a 2002:: prefix for each IPv4 border router, thereby obtaining a simple form of IPv6 multihoming by using multiple simultaneous IPv6 prefixes and multiple simultaneous relay routers. http://www.ietf.org/rfc/rfc3111.txt 3111 Service Location Protocol Modifications for IPv6. E. Guttman. May 2001. (Format: TXT=3D25543 bytes) (Status: PROPOSED STANDARD) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 2. Eliminating support for broadcast SLP requests . . . . . 3 3. Address Specification for IPv6 Addresses in URLs . . . . 3 4. SLP multicast behavior over IPv6 . . . . . . . . . . . . 4 4.1. SLPv2 Multicast Group-IDs for IPv6 . . . . . . . . . . 4 4.2. SLPv2 Scoping Rules for IPv6 . . . . . . . . . . . . . 5 4.2.1 Joining SLPv2 Multicast Groups . . . . . . . . . . . . 5 4.2.2 Sending SLPv2 Multicast Messages . . . . . . . . . . . 6 4.2.3 Rules for Message Processing . . . . . . . . . . . . . 6 4.2.4 SLPv2 Agents with multiple interfaces . . . . . . . . 7 4.2.4.1 General Rules . . . . . . . . . . . . . . . . . . . . 7 4.2.4.2 Multihomed UA . . . . . . . . . . . . . . . . . . . . 8 4.2.4.3 Multihomed SA . . . . . . . . . . . . . . . . . . . . 8 4.2.4.4 Multihomed DA . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . 13 Each interface of a multihomed device is potentially on a separate link. It is often difficult to determine whether two interfaces are connected to the same link. For that reason a prudent implementation strategy is to not issue SLP messages containing link-local service locations except on the interface where the service is known to reside. 4.2.4.2 Multihomed UA Figure 2: Multihomed UA In Figure 2 the UA is multihomed. The UA can issue a service request in Zone 1 and discover services on the SA or in Zone 2 and discover services advertised by the DA. For example, if the request is issued from a link-local source address, the SA will only reply with a service available on link 1, the DA only with a service available on link 2. 4.2.4.3 Multihomed SA Figure 3: Multihomed SA In Figure 3, the SA is multihomed. The SA may receive a request from the UA on Link 1 (Zone 1). The SA MUST NOT return service information for services offered on a different zone as a request. For example, the UA could discover services offered in Zone 1 not Zone 2. 4.2.4.4 Multihomed DA Figure 4: Multihomed DA In Figure 4, the DA is multihomed. The DA MUST keep track of which interface registrations were made on. The DA MUST prevent a registration from the SA which contains a service information valid in one zone from being discovered in another zone. For example, services registered by the SA in Zone 2 would not be discoverable by the UA in Zone 1. http://www.ietf.org/rfc/rfc3177.txt 3177 IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. (Format: TXT=3D23178 bytes) (Obsoleted = by RFC6177) (Status: INFORMATIONAL) - There are various possible approaches to multihoming for IPv6 sites, including the techniques already used for IPv4 multihoming. The main open issue is finding solutions that scale massively without unduly damaging route aggregation and/or optimal route selection. Much more work remains to be done in this area, but it seems likely that several approaches will be deployed in practice, each with their own advantages and disadvantages. Some (but not all) will work better with a fixed prefix boundary. (Multihoming is discussed in more detail below.) 5. Multihoming Issues In the realm of multi-homed networks, the techniques used in IPv4 can all be applied, but they have known scaling problems. Specifically, if the same prefix is advertised by multiple ISPs, the routing information will grow as a function of the number of multihomed sites. To go beyond this for IPv6, we only have initial proposals on the table at this time, and active work is under way in the IETF IPNG and Multi6 working groups. Until current or new proposals become more fully developed, existing techniques known to work in IPv4 will continue to be used in IPv6. http://www.ietf.org/rfc/rfc3178.txt 3178 IPv6 Multihoming Support at Site Exit Routers. J. Hagino, H. Snyder. October 2001. (Format: TXT=3D24453 bytes) (Status: INFORMATIONAL) IPv6 Multihoming Support at Site Exit Routers The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently- practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates. In IPv4, a multihomed site uses either of the following techniques to achieve better reachability: RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 This document provides a way to configure site exit routers and ISP routers, so that the site can achieve better reachability from multihomed connectivity, without impacting worldwide routing table size issues. The technique uses multiple distinct IPv6 address prefixes, assigned from multiple upstream ISPs. The technique uses an already-defined routing protocol (BGP or RIPng) and tunneling of IPv6 packets; therefore, this document introduces no new protocol standard (the document describes how to operate the configuration). RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 The RFC 2260 approach on top of IPv6 will work fine as documented in RFC 2260. There will be no extra twists necessary. Since the multihomed site is not doing transit, variations are possible that do not require it to have a public AS number. RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 The document was made possible by cooperation from people participated in JEPG-IP IPv6 multihoming study meeting (1999), people in ipngwg multihoming design team, people in WIDE/KAME project and George Tsirtsis. RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 RFC 3178 IPv6 Multihoming Support at Site Exit Routers October 2001 http://www.ietf.org/rfc/rfc3199.txt 3199 Request for Comments Summary RFC Numbers 3100-3199. S. Ginoza. February 2003. (Format: TXT=3D47287 bytes) (Status: INFORMATIONAL) 3178 Hagino Oct 2001 IPv6 Multihoming Support at Site Exit Routers The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. This memo provides information for the Internet community. http://www.ietf.org/rfc/rfc3220.txt 3220 IP Mobility Support for IPv4. C. Perkins, Ed.. January 2002. (Format: TXT=3D238343 bytes) (Obsoletes RFC2002) (Obsoleted by = RFC3344) (Status: PROPOSED STANDARD) For multihomed home agents, the source address in the outer IP header of the encapsulated datagram MUST be the address sent to the mobile node in the home agent field of the registration reply. That is, the home agent cannot use the the address of some other network interface as the source address. - In section 4.2.3, specification that multihomed home agents MUST use the the address sent to the mobile node in the home agent field of the registration reply as the source address in the outer IP header of the encapsulated datagram. http://www.ietf.org/rfc/rfc3257.txt 3257 Stream Control Transmission Protocol Applicability Statement. L. Coene. April 2002. (Format: TXT=3D24198 bytes) (Status: = INFORMATIONAL) 1. Introduction .................................................. 2 1.1 Terminology .................................................. 2 2 Transport protocols ............................................ 2 2.1 TCP service model ............................................ 2 2.2 SCTP service model ........................................... 3 2.3 UDP service model ............................................ 4 3 SCTP Multihoming issues ........................................ 4 4 SCTP Network Address Translators (NAT) issues [RFC2663] ........ 5 5 Security Considerations ........................................ 6 5.1 Security issues with TCP ..................................... 6 5.2 Security issues with SCTP .................................... 7 5.3 Security issues with both TCP and SCTP ....................... 8 6 References and related work .................................... 9 7 Acknowledgments ................................................ 10 Appendix A: Major functions provided by SCTP ..................... 11 Editor's Address ................................................. 12 Full Copyright Statement ......................................... 13 Multihoming: Assigning more than one IP network interface to a single endpoint. 3 SCTP Multihoming Issues SCTP provides transport-layer support for multihoming. Multihoming has the potential of providing additional robustness against network failures. In some applications, this may be extremely important, for example, in signaling transport of PSTN signaling messages [RFC2719]. It should be noted that SCTP multihoming support only deals with communication between two endpoints of which one or both is assigned with multiple IP addresses on possibly multiple network interfaces. It does NOT deal with communication ends that contain multiple endpoints (i.e., clustered endpoints) that can switch over to an alternate endpoint in case of failure of the original endpoint. Generally, for truly fault resilient communication between two end- points, the multihoming feature needs more than one IP network interface for each endpoint. The number of paths used is the minimum of network interfaces used by any of the endpoints. When an endpoint selects its source address, careful consideration must be taken. If the same source address is always used, then it is possible that the endpoint will be subject to the same single point of failure. When the endpoint chooses a source address, it should always select the source address of the packet to correspond to the IP address of the Network interface where the packet will be emitted subject to the binding address constraint. The binding address constraint is, put simply, that the endpoint must never choose a source address that is not part of the association i.e., the peer endpoint must recognize any source address used as being part of the association. Fig 1: SCTP through NAT without multihoming For multihoming the NAT must have a public IP address for each represented internal IP address. The host can preconfigure an IP address that the NAT can substitute, or, the NAT can have internal Application Layer Gateway (ALG) which will intelligently translate the IP addresses in the INIT and INIT ACK chunks. See Figure 2. If Network Address Port Translation is used with a multihomed SCTP endpoint, then any port translation must be applied on a per- association basis such that an SCTP endpoint continues to receive the same port number for all messages within a given association. Fig 2: SCTP through NAT with multihoming http://www.ietf.org/rfc/rfc3344.txt 3344 IP Mobility Support for IPv4. C. Perkins, Ed.. August 2002. (Format: TXT=3D241041 bytes) (Obsoletes RFC3220) (Obsoleted by = RFC5944) (Updated by RFC4721) (Status: PROPOSED STANDARD) For multihomed home agents, the source address in the outer IP header of the encapsulated datagram MUST be the address sent to the mobile node in the home agent field of the registration reply. That is, the home agent cannot use the the address of some other network interface as the source address. - In section 4.2.3, specification that multihomed home agents MUST use the the address sent to the mobile node in the home agent field of the registration reply as the source address in the outer IP header of the encapsulated datagram. http://www.ietf.org/rfc/rfc3419.txt 3419 Textual Conventions for Transport Addresses. M. Daniele, J. Schoenwaelder. December 2002. (Format: TXT=3D37466 bytes) (Status: PROPOSED STANDARD) transportDomainSctpIpv4 OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4 for global IPv4 addresses. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::=3D { transportDomains 9 } transportDomainSctpIpv6 OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6 for global IPv6 addresses. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::=3D { transportDomains 10 } transportDomainSctpIpv4z OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv4 transport domain. The corresponding transport address is of type TransportAddressIPv4z for scoped IPv4 addresses with a zone index. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::=3D { transportDomains 11 } transportDomainSctpIpv6z OBJECT-IDENTITY STATUS current DESCRIPTION "The SCTP over IPv6 transport domain. The corresponding transport address is of type TransportAddressIPv6z for scoped IPv6 addresses with a zone index. This transport domain usually represents the primary address on multihomed SCTP endpoints." ::=3D { transportDomains 12 } http://www.ietf.org/rfc/rfc3582.txt 3582 Goals for IPv6 Site-Multihoming Architectures. J. Abley, B. Black, V. Gill. August 2003. (Format: TXT=3D17045 bytes) (Status: INFORMATIONAL) Goals for IPv6 Site-Multihoming Architectures This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. Site-multihoming, i.e., connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet. Current IPv4 site-multihoming practices have been added on to the CIDR architecture [1], which assumes that routing table entries can be aggregated based upon a hierarchy of customers and service providers. However, it appears that this hierarchy is being supplanted by a dense mesh of interconnections [6]. Additionally, there has been an enormous growth in the number of multihomed sites. For purposes of redundancy and load-sharing, the multihomed address blocks are introduced into the global table even if they are covered by a provider aggregate. This contributes to the rapidly-increasing size of both the global routing table and the turbulence exhibited within it, and places stress on the inter-provider routing system. RFC 3582 IPv6 Site-Multihoming Goals August 2003 Continued growth of both the Internet and the practice of site- multihoming will seriously exacerbate this stress. The site- multihoming architecture for IPv6 should allow the routing system to scale more pleasantly. A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed. 3. Multihoming Goals 3.1. Capabilities of IPv4 Multihoming The following capabilities of current IPv4 multihoming practices should be supported by an IPv6 multihoming architecture. By multihoming, a site should be able to insulate itself from certain failure modes within one or more transit providers, as well as failures in the network providing interconnection among one or more transit providers. RFC 3582 IPv6 Site-Multihoming Goals August 2003 The multihoming architecture should accommodate (in the general case, issues of shared fate notwithstanding) continuity of connectivity during the following failures: By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This goal is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval. By multihoming, a site should be able to protect itself from performance difficulties directly between the site's transit providers. For example, suppose site E obtains transit from transit providers T1 and T2, and there is long-term congestion between T1 and T2. The multihoming architecture should allow E to ensure that in normal operation, none of its traffic is carried over the congested interconnection T1-T2. The process by which this is achieved should be a manual one. A multihomed site should be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic. RFC 3582 IPv6 Site-Multihoming Goals August 2003 A customer may choose to multihome for a variety of policy reasons beyond technical scope (e.g., cost, acceptable use conditions, etc.) For example, customer C homed to ISP A may wish to shift traffic of a certain class or application, NNTP, for example, to ISP B as matter of policy. A new IPv6 multihoming proposal should provide support for site-multihoming for external policy reasons. As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain. A new IPv6 multihoming solution should not be substantially more complex to deploy and operate (for multihomed sites or for the rest of the Internet) than current IPv4 multihoming practices. Multihoming solutions should provide re-homing transparency for transport-layer sessions; i.e., exchange of data between devices on the multihomed site and devices elsewhere on the Internet may proceed with no greater interruption than that associated with the transient packet loss during the re-homing event. Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses at the administrative boundary of the multihomed site, or at the administrative boundaries of any site in the Internet. RFC 3582 IPv6 Site-Multihoming Goals August 2003 Current IPV4 multihoming practices contribute to the significant growth currently observed in the state held in the global inter- provider routing system; this is a concern, both because of the hardware requirements it imposes, and also because of the impact on the stability of the routing system. This issue is discussed in great detail in [6]. A new IPv6 multihoming architecture should scale to accommodate orders of magnitude more multihomed sites without imposing unreasonable requirements on the routing system. The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5], and other basic IPv6 specifications current in April 2003. That is to say, if a host can work in a single-homed site, it should still be able to work in a multihomed site, even if it cannot benefit from site- multihoming. If the solution requires changes to the socket API and/or the transport layer, it should be possible to retain the original socket API and transport protocols in parallel, even if they cannot benefit from multihoming. RFC 3582 IPv6 Site-Multihoming Goals August 2003 The multihoming solution may allow host or application changes if that would enhance transport-layer survivability. It should be possible for staff responsible for the operation of a site to monitor and configure the site's multihoming system. A multihoming strategy may require cooperation between a site and its transit providers, but should not require cooperation (relating specifically to the multihomed site) directly between the transit providers. The impact of any inter-site cooperation that might be required to facilitate the multihoming solution should be examined and assessed from the point of view of operational practicality. There may be more than one approach to multihoming, provided all approaches are orthogonal (i.e., each approach addresses a distinct segment or category within the site multihoming problem). Multiple solutions will incur a greater management overhead, however, and the adopted solutions should attempt to cover as many multihoming scenarios and goals as possible. A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site. Any changes to routing practices made to accommodate multihomed sites should not cause non-multihomed sites to become more vulnerable to security breaches. RFC 3582 IPv6 Site-Multihoming Goals August 2003 RFC 3582 IPv6 Site-Multihoming Goals August 2003 RFC 3582 IPv6 Site-Multihoming Goals August 2003 http://www.ietf.org/rfc/rfc3599.txt 3599 Request for Comments Summary RFC Numbers 3500-3599. S. Ginoza. December 2003. (Format: TXT=3D76893 bytes) (Status: INFORMATIONAL) 3582 Abley Aug 2003 Goals for IPv6 Site-Multihoming Architectures This document outlines a set of goals for proposed new IPv6 site- multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here. This memo provides information for the Internet community. http://www.ietf.org/rfc/rfc3654.txt 3654 Requirements for Separation of IP Control and Forwarding. H. Khosravi, Ed., T. Anderson, Ed.. November 2003. (Format: TXT=3D40418 bytes) (Status: INFORMATIONAL) The FE model MUST be capable of supporting/allowing variations in the way logical functions are implemented on a FE. For example, on a certain FE the forwarding logical function might have information about both the next hop IP address and the next hop MAC address, while on another FE these might be implemented as separate logical functions. Another example would be NAT functionality that can have several flavors such as Traditional/Outbound NAT, Bi-directional NAT, Twice NAT, and Multihomed NAT [RFC2663]. The model must be flexible enough to allow such variations in functions. http://www.ietf.org/rfc/rfc3700.txt 3700 Internet Official Protocol Standards. J. Reynolds, Ed., S. Ginoza, Ed.. July 2004. (Format: TXT=3D148273 bytes) (Obsoletes RFC3600) (Obsoleted by RFC5000) (Status: HISTORIC) -------- Strong Security Requirements for Internet 3365 61 Engineering Task Force Standard Protocols -------- Advice to link designers on link Automatic Repeat 3366 62 reQuest (ARQ) -------- Session Initiation Protocol (SIP) for Telephones 3372 63 (SIP-T): Context and Architectures -------- Internet Assigned Numbers Authority (IANA) 3383 64 Considerations for the Lightweight Directory Access Protocol (LDAP) -------- Dynamic Delegation Discovery System (DDDS) 3405 65 Part Five: URI.ARPA Assignment Procedures -------- Uniform Resource Names (URN) Namespace Definition 3406 66 Mechanisms -------- Change Process for the Session Initiation 3427 67 Protocol (SIP) -------- Layer Two Tunneling Protocol (L2TP) Internet 3438 68 Assigned Numbers Authority (IANA) Considerations Update -------- TCP Performance Implications of Network Path 3449 69 Asymmetry -------- Guidelines for the Use of Extensible Markup 3470 70 Language (XML) within IETF Protocols -------- TCP over Second (2.5G) and Third (3G) Generation 3481 71 Wireless Networks -------- Guidelines for Writing RFC Text on Security 3552 72 Considerations -------- An IETF URN Sub-namespace for Registered Protocol 3553 73 Parameters -------- Coexistence between Version 1, Version 2, and 3584 74 Version 3 of the Internet-standard Network Management Framework -------- Session Initiation Protocol (SIP) Basic Call Flow 3665 75* Examples -------- Session Initiation Protocol (SIP) Public Switched 3666 76* Telephone -------- IETF ISOC Board of Trustee Appointment Procedures 3677 77* -------- IETF Rights in Contributions 3667 78* -------- Intellectual Property Rights in IETF Technology 3668 79* -------- Delegation of E.F.F.3.IP6.ARPA 3681 80* -------- The IETF XML Registry 3688 81* -------- Assigning Experimental and Testing Numbers 3692 82* Considered Useful -------- A Practice for Revoking Posting Rights to IETF 3683 83* Mailing Lists -------- Ingress Filtering for Multihomed Networks 3704 84* -------- Best Current Practices for Third Party Call 3725 85* Control (3pcc) in the Session Initiation Protocol (SIP) Mnemonic Title BCP# RFC# ------------------------------------------------------------------------ -------- Advice for Internet Subnetwork Designers 89 3819* -------- IANA Considerations for the Point-to-Point 88 3818* Protocol (PPP) -------- Use of Interior Gateway Protocol (IGP) Metric as 87 3785* a second MPLS Traffic Engineering (TE) Metric -------- IAB and IESG Selection, Confirmation, and Recall 10 3777* Process: Operation of the Nominating and Recall Committees -------- Determining Strengths For Public Keys Used For 86 3766* Exchanging Symmetric Keys -------- Best Current Practices for Third Party Call 85 3725* Control (3pcc) in the Session Initiation Protocol (SIP) -------- Ingress Filtering for Multihomed Networks 84 3704* -------- Assigning Experimental and Testing Numbers 82 3692* Considered Useful -------- The IETF XML Registry 81 3688* -------- A Practice for Revoking Posting Rights to IETF 83 3683* Mailing Lists -------- Delegation of E.F.F.3.IP6.ARPA 80 3681* -------- IETF ISOC Board of Trustee Appointment Procedures 77 3677* -------- Intellectual Property Rights in IETF Technology 79 3668* -------- IETF Rights in Contributions 78 3667* -------- Session Initiation Protocol (SIP) Public Switched 76 3666* Telephone -------- Session Initiation Protocol (SIP) Basic Call Flow 75 3665* Examples -------- Coexistence between Version 1, Version 2, and 74 3584 Version 3 of the Internet-standard Network Management Framework -------- An IETF URN Sub-namespace for Registered Protocol 73 3553 Parameters -------- Guidelines for Writing RFC Text on Security 72 3552 Considerations -------- TCP over Second (2.5G) and Third (3G) Generation 71 3481 Wireless Networks -------- Guidelines for the Use of Extensible Markup 70 3470 Language (XML) within IETF Protocols -------- TCP Performance Implications of Network Path 69 3449 Asymmetry -------- Layer Two Tunneling Protocol (L2TP) Internet 68 3438 Assigned Numbers Authority (IANA) Considerations Update http://www.ietf.org/rfc/rfc3704.txt 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT=3D35942 bytes) (Updates RFC2827) (Also BCP0084) (Status: BEST CURRENT PRACTICE) Ingress Filtering for Multihomed Networks BCP 38, RFC 2827, is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering, and delves into the effects on multihoming in particular. This memo updates RFC 2827. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Different Ways to Implement Ingress Filtering . . . . . . . . 4 2.1 Ingress Access Lists . . . . . . . . . . . . . . . . . . . 4 2.2 Strict Reverse Path Forwarding . . . . . . . . . . . . . . 5 2.3 Feasible Path Reverse Path Forwarding . . . . . . . . . . 6 2.4 Loose Reverse Path Forwarding . . . . . . . . . . . . . . 6 2.5 Loose Reverse Path Forwarding Ignoring Default Routes . . 7 3. Clarifying the Applicability of Ingress Filtering . . . . . . 8 3.1 Ingress Filtering at Multiple Levels . . . . . . . . . . . 8 3.2 Ingress Filtering to Protect Your Own Infrastructure . . . 8 3.3 Ingress Filtering on Peering Links . . . . . . . . . . . . 9 4. Solutions to Ingress Filtering with Multihoming . . . . . . . 9 4.1 Use Loose RPF When Appropriate . . . . . . . . . . . . . . 10 4.2 Ensure That Each ISP's Ingress Filter Is Complete . . . . 11 4.3 Send Traffic Using a Provider Prefix Only to That Provider 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Conclusions and Future Work . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 RFC 3704 Ingress Filtering for Multihomed Networks March 2004 BCP 38, RFC 2827 [1], is designed to limit the impact of distributed denial of service attacks, by denying traffic with spoofed addresses access to the network, and to help ensure that traffic is traceable to its correct source network. As a side effect of protecting the Internet against such attacks, the network implementing the solution also protects itself from this and other attacks, such as spoofed management access to networking equipment. There are cases when this may create problems, e.g., with multihoming. This document describes the current ingress filtering operational mechanisms, examines generic issues related to ingress filtering and delves into the effects on multihoming in particular. This document is aimed at ISP and edge network operators who 1) would like to learn more of ingress filtering methods in general, or 2) are already using ingress filtering to some degree but who would like to expand its use and want to avoid the pitfalls of ingress filtering in the multihomed/asymmetric scenarios. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 In section 2, several different ways to implement ingress filtering are described and examined in the generic context. In section 3, some clarifications on the applicability of ingress filtering methods are made. In section 4, ingress filtering is analyzed in detail from the multihoming perspective. In section 5, conclusions and potential future work items are identified. This section serves as an introduction to different operational techniques used to implement ingress filtering as of writing this memo. The mechanisms are described and analyzed in general terms, and multihoming-specific issues are described in Section 4. However, Ingress Access Lists are typically maintained manually; for example, forgetting to have the list updated at the ISPs if the set of prefixes changes (e.g., as a result of multihoming) might lead to discarding the packets if they do not pass the ingress filter. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 There are operational techniques, especially with BGP but somewhat applicable to other routing protocols as well, to make strict RPF work better in the case of asymmetric or multihomed traffic. The ISP assigns a better metric which is not propagated outside of the router, either a vendor-specific "weight" or a protocol distance to prefer the directly received routes. With BGP and sufficient machinery in place, setting the preferences could even be automated, using BGP Communities [2]. That way, the route will always be the best one in the FIB, even in the scenarios where only the primary connectivity would be used and typically no packets would pass RFC 3704 Ingress Filtering for Multihomed Networks March 2004 through the interface. This method assumes that there is no strict RPF filtering between the primary and secondary edge routers; in particular, when applied to multihoming to different ISPs, this assumption may fail. In the case of asymmetric routing and/or multihoming at the edge of the network, this approach provides a way to relatively easily address the biggest problems of Strict RPF. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 RFC 3704 Ingress Filtering for Multihomed Networks March 2004 RFC 3704 Ingress Filtering for Multihomed Networks March 2004 4. Solutions to Ingress Filtering with Multihoming First, one must ask why a site multihomes; for example, the edge network might: o be changing ISPs (and therefore multihoming only temporarily). One can imagine a number of approaches to working around the limitations of ingress filters for multihomed networks. Options include: 1. Do not multihome. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 RFC 3704 Ingress Filtering for Multihomed Networks March 2004 For the edge network, if multihoming is being used for robustness or to change routing from time to time depending on measured ISP behavior, the simplest approach will be to ensure that its ISPs in fact carry its addresses in routing. This will often require the edge network to use provider-independent prefixes and exchange routes with its ISPs with BGP, to ensure that its prefix is carried upstream to the major transit ISPs. Of necessity, this implies that the edge network will be of a size and technical competence to qualify for a separate address assignment and an autonomous system number from its RIR. There are a number of techniques which make it easier to ensure the ISP's ingress filter is complete. Feasible RPF and Strict RPF with operational techniques both work quite well for multihomed or asymmetric scenarios between the ISP and an edge network. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 o Feasible Path RPF check is an extension of Strict RPF. It is suitable in all the scenarios where Strict RPF is, but multihomed or asymmetric scenarios in particular. However, one must remember that Feasible RPF assumes the consistent origination and RFC 3704 Ingress Filtering for Multihomed Networks March 2004 This memo describes ingress filtering techniques in general and the options for multihomed networks in particular. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 This memo will lower the bar for the adoption of ingress filtering especially in the scenarios like asymmetric/multihomed networks where the general belief has been that ingress filtering is difficult to implement. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 [5] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001. RFC 3704 Ingress Filtering for Multihomed Networks March 2004 http://www.ietf.org/rfc/rfc3726.txt 3726 Requirements for Signaling Protocols. M. Brunner, Ed.. April 2004. (Format: TXT=3D98020 bytes) (Status: INFORMATIONAL) This document does not cover requirements in relation to some networking areas, in particular, interaction with host and site multihoming. We leave these for future analysis. http://www.ietf.org/rfc/rfc3871.txt 3871 Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure. G. Jones, Ed.. September 2004. (Format: TXT=3D151101 bytes) (Status: INFORMATIONAL) See [RFC3704] for a discussion of related issues and mechanisms for multihomed networks. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc3873.txt 3873 Stream Control Transmission Protocol (SCTP) Management Information Base (MIB). J. Pastor, M. Belinchon. September 2004. (Format: TXT=3D82403 bytes) (Status: PROPOSED STANDARD) The sctpAssocLocalAddrTable table will have as many entries as local IP addresses have been defined for the association. The sctpAssocRemAddrTable table will contain as many entries as remote IP addresses are known to reach the peer. For the multihoming concept see reference RFC2960. http://www.ietf.org/rfc/rfc3884.txt 3884 Use of IPsec Transport Mode for Dynamic Routing. J. Touch, L. Eggert, Y. Wang. September 2004. (Format: TXT=3D59437 bytes) = (Status: INFORMATIONAL) Using RFC 2003 IPIP tunnel devices [2] for VN links, instead of IPsec tunnel mode SAs, allows existing multihoming solutions for source address selection [1] to solve source address selection in this context as well. As indicated in Section 2.4, according to [1], the IP source address of an outbound packet is determined by the outbound interface, which is in turn determined by existing forwarding mechanism. Because IPIP tunnels are full-fledged interfaces with associated routes (as in Section 3.2 of [2]), the routes and address selection as specified in [1] can also operate as desired in the context of VN links. http://www.ietf.org/rfc/rfc3887.txt 3887 Message Tracking Query Protocol. T. Hansen. September 2004. (Format: TXT=3D42763 bytes) (Status: PROPOSED STANDARD) A mail system that uses multihomed mail servers has two choices for providing tracking services: either all mail servers must be running tracking servers that are able to retrieve information on all messages, or the tracking service must be performed on one (or more) machine(s) that are able to retrieve information on all messages. In the former case, no additional DNS records are needed beyond the MX records already in place for the mail system. In the latter case, SRV MTQP records are needed that point at the machine(s) that are running the tracking service. In both cases, note that the tracking service MUST be able to handle the queries for all messages accepted by that mail system. http://www.ietf.org/rfc/rfc3963.txt 3963 Network Mobility (NEMO) Basic Support Protocol. V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert. January 2005. (Format: TXT=3D75955 bytes) (Status: PROPOSED STANDARD) This document does not discuss multihoming for Mobile Routers. http://www.ietf.org/rfc/rfc3974.txt 3974 SMTP Operational Experience in Mixed IPv4/v6 Environments. M. Nakamura, J. Hagino. January 2005. (Format: TXT=3D22729 bytes) = (Status: INFORMATIONAL) The algorithm for a dual-stack SMTP sender is basically the same as that for an IPv4-only sender, but it now includes AAAA lookups of MX records for SMTP-over-IPv6 delivery. IPv4/v6 dual stack destinations should be treated just like multihomed destinations, as described in RFC 2821 [Klensin], section 5. When there is no destination address record found (i.e., the sender MTA is IPv4-only and there are no A records available), the case should be treated just like MX records without address records, and deliveries should fail. [Hagino] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001. http://www.ietf.org/rfc/rfc4029.txt 4029 Scenarios and Analysis for Introducing IPv6 into ISP Networks. M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. March 2005. = (Format: TXT=3D64388 bytes) (Status: INFORMATIONAL) 4. Backbone Transition Actions . . . . . . . . . . . . . . . . . 9 4.1. Steps in the Transition of Backbone Networks. . . . . . 9 4.1.1. MPLS Backbone . . . . . . . . . . . . . . . . . 9 4.2. Configuration of Backbone Equipment . . . . . . . . . . 10 4.3. Routing . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. IGP . . . . . . . . . . . . . . . . . . . . . . 11 4.3.2. EGP . . . . . . . . . . . . . . . . . . . . . . 12 4.3.3. Transport of Routing Protocols. . . . . . . . . 12 4.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . 13 5. Customer Connection Transition Actions. . . . . . . . . . . . 13 5.1. Steps in the Transition of Customer Connection Networks 13 5.1.1. Small End Sites . . . . . . . . . . . . . . . . 14 5.1.2. Large End Sites . . . . . . . . . . . . . . . . 15 5.2. User Authentication/Access Control Requirements . . . . 15 5.3. Configuration of Customer Equipment . . . . . . . . . . 16 5.4. Requirements for Traceability . . . . . . . . . . . . . 16 5.5. Ingress Filtering in the Customer Connection Network. . 17 5.6. Multihoming . . . . . . . . . . . . . . . . . . . . . . 17 5.7. Quality of Service. . . . . . . . . . . . . . . . . . . 17 6. Network and Service Operation Actions . . . . . . . . . . . . 18 7. Future Stages . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Requirements for Follow-On Work . . . . . . . . . . . . . . . 19 9. Example Networks. . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 22 9.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 12. Informative References. . . . . . . . . . . . . . . . . . . . 24 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 27 Full Copyright Statement. . . . . . . . . . . . . . . . . . . 28 5.6. Multihoming Customers may desire multihoming or multi-connecting for a number of reasons [RFC3582]. Mechanisms for multihoming to more than one ISP are still under discussion. One working model would deploy at least one prefix per ISP and choose the prefix from the ISP to which traffic is sent. In addition, tunnels may be used for robustness [RFC3178]. Currently, there are no provider-independent addresses for end-sites. Such addresses would enable IPv4-style multihoming, with associated disadvantages. - A tunnel server/broker mechanism, for the cases where the customer connection networks cannot be upgraded, needs to be specified [TUNREQS]. - An IPv6 site multihoming mechanism (or multiple ones) needs to be developed. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003. [RFC3178] Hagino, J. and H. Snyder, "IPv6 Multihoming Support at Site Exit Routers", RFC 3178, October 2001. http://www.ietf.org/rfc/rfc4057.txt 4057 IPv6 Enterprise Network Scenarios. J. Bound, Ed.. June 2005. (Format: TXT=3D33454 bytes) (Status: INFORMATIONAL) 4.8. Multicast................................................12 4.9. Multihoming..............................................12 5. Security Considerations........................................12 6. Normative References...........................................13 Acknowledgements...................................................13 Network Infrastructure Component 1 Enterprise Provider Requirements - Is external connectivity required? - One site vs. multiple sites and are they within different geographies? - Leased lines or VPNs? - If multiple sites, how is the traffic exchanged securely? - How many global IPv4 addresses are available to the enterprise? - What is the IPv6 address assignment plan available from the provider? - What prefix delegation is required by the Enterprise? - Will the enterprise be multihomed? - What multihoming techniques are available from the provider? - Will clients within the enterprise be multihomed? - Does the provider offer any IPv6 services? - Which site-external IPv6 routing protocols are required? - Is there an external data center to the enterprise, such as servers located at the Provider? - Is IPv6 available using the same access links as IPv4, or different ones? 4.9. Multihoming At this time, current IPv6 allocation policies are mandating the allocation of IPv6 address space from the upstream provider. If an enterprise is multihomed, the enterprise will have to determine how it wishes to support multihoming. This also is an area of study within the IETF and work in progress. http://www.ietf.org/rfc/rfc4080.txt 4080 Next Steps in Signaling (NSIS): Framework. R. Hancock, G. Karagiannis, J. Loughney, S. Van den Bosch. June 2005. (Format: TXT=3D122470 bytes) (Status: INFORMATIONAL) 3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7 3.1.3. Signaling to Hosts, Networks, and Proxies ...........8 3.1.4. Signaling Messages and Network Control State .......10 3.1.5. Data Flows and Sessions ............................10 3.2. Layer Model for the Protocol Suite ........................11 3.2.1. Layer Model Overview ...............................11 3.2.2. Layer Split Concept ................................12 3.2.3. Bypassing Intermediate Nodes .......................13 3.2.4. Core NSIS Transport Layer Functionality ............15 3.2.5. State Management Functionality .....................16 3.2.6. Path-Decoupled Operation ...........................17 3.3. Signaling Application Properties ..........................18 3.3.1. Sender/Receiver Orientation ........................18 3.3.2. Uni- and Bi-Directional Operation ..................19 3.3.3. Heterogeneous Operation ............................19 3.3.4. Aggregation ........................................20 3.3.5. Peer-Peer and End-End Relationships ................21 3.3.6. Acknowledgements and Notifications .................21 3.3.7. Security and Other AAA Issues ......................22 4. The NSIS Transport Layer Protocol ..............................23 4.1. Internal Protocol Components ..............................23 4.2. Addressing ................................................24 4.3. Classical Transport Functions .............................24 4.4. Lower Layer Interfaces ....................................26 4.5. Upper Layer Services ......................................27 4.6. Identity Elements .........................................28 4.6.1. Flow Identification ................................28 4.6.2. Session Identification .............................28 4.6.3. Signaling Application Identification ...............29 4.7. Security Properties .......................................30 5. Interactions with Other Protocols ..............................30 5.1. IP Routing Interactions ...................................30 5.1.1. Load Sharing and Policy-Based Forwarding ...........31 5.1.2. Route Changes ......................................31 5.2. Mobility and Multihoming Interactions .....................33 5.3. Interactions with NATs ....................................36 5.4. Interactions with IP Tunneling ............................36 6. Signaling Applications .........................................37 6.1. Signaling for Quality of Service ..........................37 6.1.1. Protocol Message Semantics .........................38 6.1.2. State Management ...................................39 6.1.3. Route Changes and QoS Reservations .................39 6.1.4. Resource Management Interactions ...................41 6.2. Other Signaling Applications ..............................42 7. Security Considerations ........................................42 8. References .....................................................43 8.1. Normative References ......................................43 8.2. Informative References ....................................44 However, for some more complex scenarios (especially mobility and multihoming related ones; see [1] and the mobility discussion of [5]), it is desirable to update the flow:session mapping during the session lifetime. For example, a new flow can be added, and the old one deleted (and maybe in that order, for a 'make-before-break' handover), effectively transferring the network control state between data flows to keep it associated with the same session. Such updates are best managed by the end systems (generally, systems that understand the flow:session mapping and are aware of the packet classifier change). To enable this, it must be possible to relate signaling messages to sessions as well as to data flows. A session identifier (Section 4.6.2) is one component of the solution. 5.2. Mobility and Multihoming Interactions The issues associated with mobility and multihoming are a generalization of the basic route change case of the previous section. As well as the fact that packets for a given session are no longer traveling over a single topological path, the following extra considerations arise: 1. The use of IP-layer mobility and multihoming means that more than one IP source or destination address will be associated with a single session. The same applies if application-layer solutions (e.g., SIP-based approaches) are used. 3. The double route may persist for some time in the network (e.g., in the case of a 'make-before-break' handover being done by a multihomed host). Note that the crossover router discovery may involve end-to-end signaling exchanges (especially for flows towards the mobile or multihomed node), which raises a latency concern. On the other hand, end-to-end signaling will have been necessary in any case, at the application level not only to communicate changed addresses, but also to update packet classifiers along the path. It is a matter for further analysis to decide how these exchanges could be combined or carried out in parallel. http://www.ietf.org/rfc/rfc4116.txt 4116 IPv4 Multihoming Practices and Limitations. J. Abley, K. Lindqvist, E. Davies, B. Black, V. Gill. July 2005. (Format: TXT=3D26598 bytes) (Status: INFORMATIONAL) IPv4 Multihoming Practices and Limitations Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6). RFC 4116 IPv4 Multihoming July 2005 1. Introduction ....................................................3 2. Terminology .....................................................3 3. IPv4 Multihoming Practices ......................................4 3.1. Multihoming with BGP .......................................4 3.1.1. Addressing Considerations ...........................4 3.1.2. AS Number Considerations ............................6 3.2. Multiple Attachments to a Single Transit Provider ..........6 3.3. NAT- or RFC2260-based Multihoming ..........................7 4. Features of IPv4 Multihoming ....................................7 4.1. Redundancy .................................................7 4.2. Load Sharing ...............................................8 4.3. Performance ................................................8 4.4. Policy .....................................................8 4.5. Simplicity .................................................9 4.6. Transport-Layer Survivability ..............................9 4.7. Impact on DNS ..............................................9 4.8. Packet Filtering ...........................................9 4.9. Scalability ................................................9 4.10. Impact on Routers ........................................10 4.11. Impact on Hosts ..........................................10 4.12. Interactions between Hosts and the Routing System ........10 4.13. Operations and Management ................................10 4.14. Cooperation between Transit Providers ....................10 5. Security Considerations ........................................10 6. Acknowledgements ...............................................10 7. Informative References .........................................11 RFC 4116 IPv4 Multihoming July 2005 Multihoming is an important component of service for many Internet sites. Current IPv4 multihoming practices have been added on to the Classless Inter Domain Routing (CIDR) architecture [RFC1519], which assumes that routing table entries can be aggregated based upon a hierarchy of customers and service providers. Multihoming is a mechanism by which sites can satisfy a number of high-level requirements. It is widely used in the IPv4 Internet. There are some practical limitations, however, including concerns as to how it would scale with future Internet growth. This document aims to document common IPv4 multihoming practices and enumerate their features for comparison with other multihoming approaches. There are a number of different ways to route and manage traffic in and out of a multihomed site: the majority rely on the routing policy capabilities of the inter-domain routing protocol, the Border Gateway Protocol, version 4 (BGP) [RFC1771]. This document also discusses a multi-homing strategy which does not rely on the capabilities of BGP. A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed. RFC 4116 IPv4 Multihoming July 2005 3. IPv4 Multihoming Practices 3.1. Multihoming with BGP The general approach for multihoming with BGP is to announce a set of routes to two or more transit providers. This provides the rest of the Internet with multiple paths back to the multihomed sites, and each transit provider provides an additional possible path for the site's outbound traffic. Using PI addresses has long been the preferred approach for IPv4 multihoming. Until the mid-1990s this was relatively easy to accomplish, as the maximum generally accepted prefix length in the global routing table was a /24, and little justification was needed to obtain a /24 PI assignment. Since then, RIR address management policies have become less liberal in this respect. Not all RIRs support the assignment of address blocks to small, multihomed end- users, and those that do support it require justification for blocks as large as a /24, which cannot be met by small sites. As a consequence, PI addresses are not available to many sites who wish to multihome. Each site that uses PI addresses introduces an additional prefix into the global routing system. If this scheme for multihoming became widespread, it would present scaling concerns. RFC 4116 IPv4 Multihoming July 2005 There have been well-documented examples of sites filtering long- prefix routes which are covered by a transit-providers aggregate. If this practice were to become very widespread, it might limit the effectiveness of multihoming using PA addresses. However, limited filtering of this kind can be tolerated because the aggregate announcements of the primary transit provider should be sufficient to attract traffic from autonomous systems which do not accept the covered site route set. The more traffic that follows the primary transit provider's aggregate in the absence of the covered, more- specific route, the greater the reliance on that primary transit provider. In some cases, this reliance might result in an effective single point of failure. Traffic following the primary transit provider's aggregate routes may still be able to reach the multihomed site, even in the case where the connection between the primary transit provider and the site has failed. The site route set will still be propagating through the site's other transit providers. If that route set reaches (and is accepted by) the primary transit provider, connectivity for traffic following the aggregate route will be preserved. Sites that use PA addresses are usually obliged to renumber if they decide not to retain connectivity to the primary transit provider. While this is a common requirement for all sites using PA addresses (and not just those that are multihomed), it is one that may have more frequent impact on sites whose motivation to multihome is to facilitate changes of ISP. A multihomed site using PA addresses can still add or drop other service providers without having to renumber. RFC 4116 IPv4 Multihoming July 2005 A multihomed site may choose to announce routes to two or more transit providers from a globally-unique Autonomous System (AS) number assigned to the site. This causes the origin of the route to appear consistent when viewed from all parts of the Internet. A multihomed site may choose to use a private-use AS number [RFC1930] to originate routes to transit providers. It is normal practice for private-use AS numbers to be stripped from AS_PATH attributes before they are allowed to propagate from transit providers towards peers. Therefore, routes observed from other parts of the Internet may appear to have inconsistent origins. A multihomed site may request that their transit providers each originate the site's routes from the transit providers' ASes. Dynamic routing (for the purposes of withdrawing the site's route in the event that connectivity to the site is lost) is still possible, in this case, using the transit providers' internal routing systems to trigger the externally-visible announcements. Operational troubleshooting is facilitated by the use of a consistent origin AS. This allows import policies to be based on a route's true origin rather than on intermediate routing details, which may change (e.g., as transit providers are added and dropped by the multihomed site). Multihoming can be achieved through multiple connections to a single transit provider. This imposes no additional load on the global routing table beyond that involved in the site being single-attached. A site that has solved its multihoming needs in this way is commonly referred to as "multi-attached". RFC 4116 IPv4 Multihoming July 2005 3.3. NAT- or RFC2260-based Multihoming This method uses PA addresses assigned by each transit provider to which the site is connected. The addresses are either allocated to individual hosts within the network according to [RFC2260], or the site uses Network Address Translation (NAT) to translate the various provider addresses into a single set of private-use addresses [RFC1918] within the site. The site is effectively singlehomed to more than one transit provider. None of the transit providers need to make any accommodations beyond those typically made for a non- multihomed customer. This approach accommodates a wide range of sites, from residential Internet users to very large enterprises, requires no PI addresses or AS numbers, and imposes no additional load on the Internet's global routing system. However, it does not address several common motivations for multihoming, most notably transport-layer survivability. 4. Features of IPv4 Multihoming The following sections describe some of the features of the approaches described in Section 3, in the context of the general goals for multihoming architectures presented in [RFC3582]. Detailed descriptions and rationale for these goals can be found in that document. RFC 4116 IPv4 Multihoming July 2005 All of the methods described provide some measure of load-sharing capability. Outbound traffic can be shared across ISPs using appropriate exit selection policies; inbound traffic can be distributed using appropriate export policies designed to influence the exit selection of remote sites sending traffic back towards the multihomed site. In the case of RFC2260/NAT multihoming, distribution of inbound traffic is controlled by address selection on the host or NAT. In the case of RFC2260/NAT multihoming in the absence of BGP routing information, management of outbound traffic is not possible. The path taken by inbound traffic for a particular session can be controlled by source address selection on the host or NAT. In the case of RFC2260/NAT multihoming, policies such as those described here can be accommodated by appropriate address selection on the host or NAT. More flexible implementations may be possible for sessions originated from the multihomed site by selecting an appropriate source address on a host or NAT, according to criteria such as transport-layer protocols and addresses (ports). RFC 4116 IPv4 Multihoming July 2005 The current methods used as multihoming solutions are not without their complexities, but have proven to be sufficiently simple to be used. They have the advantage of familiarity due to having been deployed extensively. All BGP-based multihoming practices provide some degree of session survivability for transport-layer protocols. However, in cases where path convergence takes a long time following a re-homing event, sessions may time out. Transport-layer sessions will not, in general, survive over a re- homing event when using RFC2260/NAT multihoming. Transport protocols which support multiple volatile endpoint addresses may be able to provide session stability; however, these transport protocols are not in wide use. These multihoming strategies impose no new requirements on the DNS. These multihoming practices do not preclude filtering of packets with inappropriate source or destination addresses at the administrative boundary of the multihomed site. Current IPv4 multihoming practices are thought to contribute to significant observed growth in the amount of state held in the global inter-provider routing system. This is a concern because of both the hardware requirements it imposes and the impact on the stability of the routing system. This issue is discussed in greater detail in [RFC3221]. Of the methods presented in this document, RFC2260/NAT multihoming and multi-attaching to a single transit provider provide no additional state to be held in the global routing system. All other strategies contribute to routing system state bloat. RFC 4116 IPv4 Multihoming July 2005 Globally-unique AS numbers are a finite resource. Thus, widespread multihoming that uses strategies requiring assignment of AS numbers might lead to increased resource contention. For some of the multihoming approaches described in this document, the routers at the boundary of the multihomed site are required to participate in BGP sessions with transit provider routers. Other routers within the site generally have no special requirements beyond those in singlehomed sites. There is extensive operational experience in managing IPv4-multihomed sites. This document discusses current IPv4 multihoming practices, but provides no analysis of the security implications of multihoming. RFC 4116 IPv4 Multihoming July 2005 [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. RFC 4116 IPv4 Multihoming July 2005 RFC 4116 IPv4 Multihoming July 2005 http://www.ietf.org/rfc/rfc4140.txt 4140 Hierarchical Mobile IPv6 Mobility Management (HMIPv6). H. Soliman, C. Castelluccia, K. El Malki, L. Bellier. August 2005. (Format: TXT=3D71503 bytes) (Obsoleted by RFC5380) (Status: EXPERIMENTAL) If a multihomed mobile node has access to several ARs simultaneously (on different interfaces), it SHOULD use an LCoA on the link defined by the AR that advertises its current MAP. http://www.ietf.org/rfc/rfc4168.txt 4168 The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP). J. Rosenberg, H. Schulzrinne, G. Camarillo. October 2005. (Format: TXT=3D21079 = bytes) (Status: PROPOSED STANDARD) Multihoming: An SCTP connection can be associated with multiple IP addresses on the same host. Data is always sent over one of the addresses, but if it becomes unreachable, data sent to one can migrate to a different address. This improves fault tolerance; network failures making one interface of the server unavailable do not prevent the service from continuing to operate. SIP servers are likely to have substantial fault tolerance requirements. It is worth noting that, because SIP is message oriented and not stream oriented, the existing SRV (Service Selection) procedures defined in [5] can accomplish the same goal, even when SIP is run over TCP. In fact, SRV records allow the 'connection' to fail over to a separate host. Since SIP proxies can run statelessly, failover can be accomplished without data synchronization between the primary and its backups. Thus, the multihoming capabilities of SCTP provide marginal benefits. http://www.ietf.org/rfc/rfc4177.txt 4177 Architectural Approaches to Multi-homing for IPv6. G. Huston. September 2005. (Format: TXT=3D95374 bytes) (Status: INFORMATIONAL) [RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003. http://www.ietf.org/rfc/rfc4192.txt 4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F. Baker, E. Lear, R. Droms. September 2005. (Format: TXT=3D52110 = bytes) (Updates RFC2072) (Status: INFORMATIONAL) 1. Introduction ....................................................2 1.1. Summary of the Renumbering Procedure .......................3 1.2. Terminology ................................................4 1.3. Summary of What Must Be Changed ............................4 1.4. Multihoming Issues .........................................5 2. Detailed Review of Procedure ....................................5 2.1. Initial Condition: Stable Using the Old Prefix .............6 2.2. Preparation for the Renumbering Process ....................6 2.2.1. Domain Name Service .................................7 2.2.2. Mechanisms for Address Assignment to Interfaces .....7 2.3. Configuring Network Elements for the New Prefix ............8 2.4. Adding New Host Addresses ..................................9 2.5. Stable Use of Either Prefix ...............................10 2.6. Transition from Use of the Old Prefix to the New Prefix ...10 2.6.1. Transition of DNS Service to the New Prefix ........10 2.6.2. Transition to Use of New Addresses .................10 2.7. Removing the Old Prefix ...................................11 2.8. Final Condition: Stable Using the New Prefix ..............11 3. How to Avoid Shooting Yourself in the Foot .....................12 3.1. Applications Affected by Renumbering ......................12 3.2. Renumbering Switch and Router Interfaces ..................12 3.3. Ingress Filtering .........................................13 3.4. Link Flaps in BGP Routing .................................13 4. Call to Action for the IETF ....................................14 4.1. Dynamic Updates to DNS Across Administrative Domains ......14 4.2. Management of the Reverse Zone ............................14 5. Security Considerations ........................................14 6. Acknowledgements ...............................................16 7. References .....................................................17 7.1. Normative References ......................................17 7.2. Informative References ....................................17 Appendix A. Managing Latency in the DNS ..........................20 1.4. Multihoming Issues In addition to the considerations presented, the operational matters of multihoming may need to be addressed. Networks are generally renumbered for one of three reasons: the network itself is changing its addressing policy and must renumber to implement the new policy (for example, a company has been acquired and is changing addresses to those used by its new owner), an upstream provider has changed its prefixes and its customers are forced to do so at the same time, or a company is changing providers and must perforce use addresses assigned by the new provider. The third case is common. When a company changes providers, it is common to institute an overlap period, during which it is served by both providers. By definition, the company is multihomed during such a period. Although this document is not about multihoming per se, problems can arise as a result of ingress filtering policies applied by the upstream provider or one of its upstream providers, so the user of this document also needs to be cognizant of these issues. This is discussed in detail, and approaches to dealing with it are described, in [RFC2827] and [RFC3704]. An important consideration in Section 2.3, in the case where the network being renumbered is connected to an external provider, is the network's ingress filtering policy and its provider's ingress filtering policy. Both the network firewall's ingress filter and the provider's ingress filter on the access link to the network should be configured to prevent attacks that use source address spoofing. Ingress filtering is considered in detail in "Ingress Filtering for Multihomed Networks" [RFC3704]. In ingress filtering of a multihomed network, an easy solution to the issues raised in Section 3.3 might recommend that ingress filtering should not be done for multihomed customers or that ingress filtering should be special-cased. However, this has an impact on Internet security. A sufficient level of ingress filtering is needed to prevent attacks using spoofed source addresses. Another problem comes from the fact that if ingress filtering is made too difficult (e.g., by requiring special-casing in every ISP doing it), it might not be done at an ISP at all. Therefore, any mechanism depending on relaxing ingress filtering checks should be dealt with with extreme care. temporarily or permanently create a multihomed network by renumbering from one provider to another. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4213.txt 4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E. Nordmark, R. Gilligan. October 2005. (Format: TXT=3D58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4218.txt 4218 Threats Relating to IPv6 Multihoming Solutions. E. Nordmark, T. Li. October 2005. (Format: TXT=3D75969 bytes) (Status: = INFORMATIONAL) Threats Relating to IPv6 Multihoming Solutions This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure; we examine threats that are inherent to all IPv6 multihoming solutions rather than study any specific proposed solution. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 The goal of the IPv6 multihoming work is to allow a site to take advantage of multiple attachments to the global Internet, without having a specific entry for the site visible in the global routing table. Specifically, a solution should allow hosts to use multiple attachments in parallel, or to switch between these attachment points dynamically in the case of failures, without an impact on the transport and application layer protocols. This document has been developed while considering multihoming solutions architected around a separation of network identity and network location, whether or not this separation implies the introduction of a new and separate identifier name space. However, this separation is not a requirement for all threats, so this taxonomy may also apply to other approaches. This document is not intended to examine any single proposed solution. Rather, it is intended as an aid to discussion and evaluation of proposed solutions. By cataloging known threats, we can help to ensure that all proposals deal with all of the available threats. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 2) How does the solution apply multihoming to IP multicast? Depending on how this is done, there might be specific threats relating to multicast that need to be understood. This document does not discuss any multicast-specific threats. This threat analysis doesn't assume that security has been applied to other security relevant parts of the Internet, such as DNS and routing protocols; but it does assume that, at some point in time, at least parts of the Internet will be operating with security for such key infrastructure. With that assumption, it then becomes important that a multihoming solution would not, at that point in time, become the weakest link. This is the case even if, for instance, insecure DNS might be the weakest link today. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 The document assumes that an off-path attacker can neither see packets between the peers (for which it is not on the path) nor block them from being delivered. Off-path attackers can, in general, send packets with arbitrary IP source addresses and content, but such packets might be blocked if ingress filtering [INGRESS] is applied. Thus, it is important to look at the multihoming impact on security both in the presence and absence of ingress filtering. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 The two interesting aspects of security for multihoming solutions are (1) the assumptions made by the transport layer and application layer protocols about the identifiers that they see, and (2) the existing abilities to perform various attacks that are related to the identity/location relationship. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 The third class of security configurations receives existing IP source addresses, but attempt some verification using the DNS, effectively using the FQDN for access control. (This is typically done by performing a reverse lookup from the IP address, followed by a forward lookup and verifying that the IP address matches one of the addresses returned from the forward lookup.) These applications are already subject to a number of attacks using techniques like source address spoofing and TCP sequence number guessing since an attacker, knowing this is the case, can simply create a DoS attack using a forged source address that has authentic DNS records. In general this class of security configurations is strongly discouraged, but it is probably important that a multihoming solution doesn't introduce any new and easier ways to perform such attacks. However, we note that some people think we should treat this class the same as the second class of security configurations. The fourth class of security configurations uses cryptographic security techniques to provide both a strong identity for the peer and data integrity with or without confidentiality. Such systems are still potentially vulnerable to denial of service attacks that could be introduced by a multihoming solution. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 The fifth class is important and its security properties must be preserved by a multihoming solution. The requirement for a multihoming solution is that security be no worse than it is today in all situations. Thus, mechanisms that provide confidentiality, integrity, or authentication today should continue to provide these properties in a multihomed environment. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 All of the above protocol attacks are the subject of ongoing work to secure them (DNSsec, security for BGP, Secure ND) and are not considered further within this document. The goal for a multihoming solution is not to solve these attacks. Rather, it is to avoid adding to this list of attacks. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 We don't expect a multihoming solution to improve the existing degree of prevention against packet injection. However, it is necessary to look carefully at whether a multihoming solution makes it easier for attackers to inject packets because the desire to have the peer present at multiple locators, and perhaps at a dynamic set of locators, can potentially result in solutions that, even in the presence of ingress filtering, make packet injection easier. Devices on the path between two communicating entities can also launch DoS attacks. While such attacks might not be interesting today, it is necessary to understand them better in order to determine whether a multihoming solution might enable new types of DoS attacks. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 The danger is that the addition of multihoming redirection mechanisms might potentially remove the constraint that the attacker remain on the path. And with the current, no-multihoming support, using end-to-end strong security at a protocol level at (or below) this "ACK" processing would prevent this type of attack. But if a multihoming solution is provided underneath IPsec that prevention mechanism would potentially not exist. Thus, the challenge for multihoming solutions is to not create additional types of attacks in this area, or make existing types of attacks significantly easier. We also observe that a common practice in IPv4 today is to use some form of address translation, whether the site is multihomed or not. This effectively hides the identity of the specific host within a site; only the site can be identified based on the IP address. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 Today when a site is multihomed to multiple ISPs, the common setup is that a single IP address prefix is used with all the ISPs. As a result it is possible to track that it is the same host that is communication via all ISPs. However, when a host (and not a site) is multi-homed to several ISPs (e.g., through a General Packet Radio Service (GPRS) connection and a wireless hot spot), the host is provided with different IP addresses on each interface. While the focus of the multihoming work is on site multihoming, should the solution also be applicable to host multihoming, the privacy impact needs to be considered for this case as well. Given that there is no address privacy in site multihoming setups today, the primary concerns for the "do no harm" criteria are to ensure that hosts that move around still have the same ability as in today's Internet to choose between seamless connectivity and improved address privacy, and also that the introduction of multihoming support should still provide the same ability as we have in IPv6 with temporary addresses. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 Note that such attacks are always possible today if an attacker is on the path between two communicating parties, and a multihoming solution can't remove that threat. Hence, the bulk of these concerns relate to off-path attackers. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 It would be reasonable to require that a multihoming solution limit the ability to redirect and/or DoS traffic to a few minutes after the attacker has moved off the path. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 While the multihoming problem doesn't inherently imply any topological movement, it is useful to also consider the impact of site renumbering in combination with multihoming. In that case, the set of locators for a host will change each time its site renumbers, and, at some point in time after a renumbering event, the old locator prefix might be reassigned to some other site. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 If this type of attack can't be prevented, there might be mitigation techniques that can be employed. For instance, in the case of TCP a partial defense can be constructed by having TCP slow-start be triggered when the destination locator changes. (Folks might argue that, separately from security, this would be the correct action for congestion control since TCP might not have any congestion-relation information about the new path implied by the new locator.) Presumably the same approach can be applied to other transport protocols that perform different forms of (TCP-friendly) congestion control, even though some of them might not adapt as rapidly as TCP. But since all congestion-controlled protocols probably need to have some reaction to the path change implied by a locator change, it makes sense to think about 3rd party DoS attacks when designing how the specific transport protocols should react to a locator change. However, this would only be a partial solution since it would probably take several packets and roundtrips before the transport protocol would stop transmitting; thus, an attacker could still use this as a reflector with packet amplification. Thus, the multihoming mechanism probably needs some form of defense against third party DoS attacks, in addition to the help we can get from the transport protocols. X could flood A directly but is limited by its low bandwidth. If X can establish communication with B, ask B to send it a high-speed media stream, then X can presumably fake out the "acknowledgements/feedback" needed for B to blast out packets at full speed. So far, this only hurts X and the path between X and the Internet. But if X could also tell B "I'm at A's locator", then X has effectively used this redirection capability in multihoming to amplify its DoS capability, which would be a source of concern. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 A third way that a multihoming solution might address this is to ensure that B will only accept locators that can be authenticated to be synonymous with the original correspondent. It must be possible to securely ensure that these locators form an equivalence class. So in the first example, not only does X need to assert that it is A, but A needs to assert that it is X. The multihoming solution space does not only affect the destination of packets; it also raises the question from which sources packets should be accepted. It is possible to build a multihoming solution that allows traffic to be recognized as coming from the same peer even if there is a previously unknown locator present in the source address field. The question is whether we want to allow packets from unverified sources to be passed on to transport and application layer protocols. In the current Internet, an attacker can't inject packets with arbitrary source addresses into a session if there is ingress filtering present, so allowing packets with unverified sources in a multihoming solution would fail our "no worse than what we have now" litmus test. However, given that ingress filtering deployment is far from universal and ingress filtering typically wouldn't prevent spoofing of addresses in the same subnet, requiring rejecting packets from unverified locators might be too stringent. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 A factor to take into account to determine the "requirement level" for this is that when IPsec is used on top of the multihoming solution, then IPsec will reject such spoofed packets. (Note that this is different than in the redirection attack cases where even with IPsec an attacker could potentially cause a DoS attack.) While introducing identifiers can be helpful by providing ways to identify hosts across events when its IP address(es) might change, there is a risk that such mechanisms can be abused to track the identity of the host over long periods of time, whether using the same (set of) ISP(s) or moving between different network attachment points. Designers of solutions to multihoming need to be aware of this concern. Introducing the multihoming capability inherently implies that the communicating peers need to know multiple locators for each other in order to be resilient to failures of some paths/locators. In addition, if the multihoming signaling protocol doesn't provide privacy, it might be possible for 3rd parties on the path to discover many or all the locators assigned to a host, which would increase the privacy exposure compared to a multihomed host today. Different multihoming solutions might approach the problem at different layers in the protocol stack. For instance, there have been proposals for a shim layer inside IP, as well as transport layer approaches. The former would have the capability to redirect an IP address while the latter might be constrained to only redirect a single transport connection. This difference might be important when it comes to understanding the security impact. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 For instance, premeditated attacks might have quite different impact in the two cases. In an IP-based multihoming solution a successful premeditated redirection could be due to the attacker connecting to a server and claiming to be 'A', which would result in the server retaining some state about 'A', which it received from the attacker. Later, when the real 'A' tries to connect to the server, the existence of this state might mean that 'A' fails to communicate, or that its packets are sent to the attacker. But if the same scenario is applied to a transport-layer approach, then the state created due to the attacker would perhaps be limited to the existing transport connection. Thus, while this might prevent the real 'A' from connecting to the server while the attacker is connected (if they happen to use the same transport port number), most likely it would not affect 'A's ability to connect after the attacker has disconnected. Note that transport layer approaches are limited to the set of "transport" protocols that the implementation makes aware of multihoming. In many cases there would be "transport" protocols that are unknown to the multihoming capability of the system, such as applications built on top of UDP. To understand the impact of the granularity question on the security, one would also need to understand how such applications/protocols would be handled. A property of transport granularity is that the amount of work performed by a legitimate host is proportional to the number of transport connections it creates that uses the multihoming support, since each such connection would require some multihoming signaling. And the same is true for the attacker. This means that an attacker could presumably do a premeditated attack for all TCP connections to port 80 from A to B, by setting up 65,536 (for all TCP source port numbers) connections to server B and causing B to think those connections should be directed to the attacker and keeping those TCP connections open. Any attempt to make legitimate communication more efficient (e.g., by being able to signal for multiple transport connections at a time) would provide as much relative benefit for an attacker as the legitimate hosts. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 The issue isn't only about the space (granularity), but also about the lifetime component in the results of a multihoming request. In a transport-layer approach, the multihoming state would presumably be destroyed when the transport state is deleted as part of closing the connection. But an IP-layer approach would have to rely on some timeout or garbage collection mechanisms, perhaps combined with some new explicit signaling, to remove the multihoming state. The coupling between the connection state and multihoming state in the transport-layer approach might make it more expensive for the attacker, since it needs to keep the connections open. In summary, there are issues we don't yet understand well about granularity and reuse of the multihoming state. In the case when nothing moves around, we have a reasonable understanding of the security requirements. Something that is on the path can be a MITM in today's Internet, and a multihoming solution doesn't need to make that aspect any more secure. But it is more difficult to understand the requirements when hosts are moving around. For instance, a host might be on the path for a short moment in time by driving by an 802.11 hotspot. Would we or would we not be concerned if such a drive-by (which many call a "time-shifting" attack) would result in the temporarily on-path host being able to act as a MITM for future communication? Depending on the solution, this might be possible if the attacker causes a multihoming state to be created in various peer hosts while the attacker was on the path, and that state remained in the peers for some time. The answer to this question doesn't seem to be obvious even in the absence of any new multihoming support. We don't have much experience with hosts moving around that are able to attack things as they move. In Mobile IPv6 [MIPv6] a conservative approach was taken that limits the effect of such drive-by attacks to the maximum lifetime of the binding, which is set to a few minutes. With multihoming support the issue gets a bit more complicated because we explicitly want to allow a host to be present at multiple locators at the same time. Thus, there might be a need to distinguish between the host moving between different locators, and the host sending packets with different source locators because it is present at multiple locators without any topological movement. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 Note that the multihoming solutions that have been discussed range from such "drive-by" attacks being impossible (for instance, due to a strong binding to a separate identifier as in HIP, or due to reliance on the relative security of the DNS for forward plus reverse lookups in NOID), to systems that are first-come/first-serve (WIMP being an example with a separate ID space, a MAST approach with a PBK being an example without a separate ID space) that allow the first host that uses an ID/address to claim it without any time limit. The protocol mechanisms added as part of a multihoming solution shouldn't introduce any new DoS in the mechanisms themselves. In particular, care must be taken not to: Another possible approach is to first establish communications, and then perform verification in parallel with normal data transfers. Redirection would only be permitted after verification was complete, but prior to that event, data could transfer in a normal, non-multihomed manner. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 can also redirect packets. This could be possible, for instance, by physical break-ins or by bribing staff that have access to the physical infrastructure. Such attacks are out of scope of this discussion, but are worth keeping in mind when looking at the cost for an attacker to exploit any protocol-based attacks against multihoming solutions; making protocol-based attacks much more expensive to launch than break-ins/bribery type of attacks might be overkill. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 [NOID] Erik Nordmark, "Multihoming without IP Identifiers", Work in Progress, July 2004. [WIMP] Jukka Ylitalo, "Weak Identifier Multihoming Protocol (WIMP)", Work in Progress, June 2004. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 When looking at the proposals that have been made for multihoming solutions and the above threats, it seems like there are two separable aspects of handling the redirection threats: RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 However, the mechanisms for preventing unauthorized use of an identifier can be quite different. One way to prevent premeditated redirection is to simply not introduce a new identifier name space, and instead to rely on existing name space(s), a trusted third party, and a sufficiently secure way to access the third party, as in [NOID]. Such an approach relies on the third party (DNS in the case of NOID) as the foundation. In terms of multihoming state creation, in this case premeditated redirection is as easy or as hard as redirecting an IP address today. Essentially, this relies on the return-routability check associated with a roundtrip of communication, which verifies that the routing system delivers packets to the IP address in question. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 A related, but perhaps separate aspect, is whether the solution provides for protection against man-in-the-middle attacks with on-path attackers. Some schemes, such as [HIP] and [NOID] do, but given that an on-path attacker can see and modify the data traffic whether or not it can modify the multihoming signaling, this level of protection seems like overkill. Protecting against on-path MITM for the data traffic can be done separately using IPsec, TLS, etc. RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 RFC 4218 Threats to IPv6 Multihoming Solutions October 2005 http://www.ietf.org/rfc/rfc4219.txt 4219 Things Multihoming in IPv6 (MULTI6) Developers Should Think About. E. Lear. October 2005. (Format: TXT=3D25141 bytes) (Status: INFORMATIONAL) Things Multihoming in IPv6 (MULTI6) Developers Should Think About This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution. 1. Introduction ....................................................3 1.1. Reading this Document ......................................3 2. On the Wire Behavior ............................................4 2.1. How will your solution solve the multihoming problem? ......4 2.2. At what layer is your solution applied, and how? ...........4 2.3. Why is the layer you chose the correct one? ................4 2.4. Does your solution address mobility? .......................4 2.5. Does your solution expand the size of an IP packet? ........4 2.6. Will your solution add additional latency? .................4 2.7. Can multihoming capabilities be negotiated end-to-end during a ........................................4 2.8. Do you change the way fragmenting is handled? ..............5 2.9. Are there any layer 2 implications to your proposal? .......5 3. Identifiers and Locators ........................................5 3.1. Uniqueness .................................................5 3.2. Does your solution provide for a split between identifiers and ............................................5 3.3. What is the lifetime of a binding from an identifier to a locator? ...................................5 3.4. How is the binding updated? ................................5 3.5. How does a host know its identity? .........................5 3.6. Can a host have multiple identifiers? ......................5 3.7. If you have separate locators and identifiers, how will they be ...............................................5 3.8. Does your solution create an alternate "DNS-like" service? ...................................................5 3.9. Please describe authentication/authorization ...............6 3.10. Is your mechanism hierarchical? ...........................6 3.11. Middlebox interactions ....................................6 3.12. Are there any implications for scoped addressing? .........6 4. Routing System Interactions .....................................6 4.1. Does your solution change existing aggregation methods? ....6 4.2. Does the solution solve traffic engineering requirements? ..7 4.3. Does the solution offer ways for the site to manage its traffic ................................................7 4.4. If you introduce any new name spaces, do they require aggregation? .......................................7 4.5. Does your solution interact with Autonomous System numbering? .................................................7 4.6. Are there any changes to ICMP error semantics? .............7 5. Name Service Interactions .......................................7 5.1. Please explain the relationship of your solution to DNS ....7 5.2. Please explain interactions with "2-faced" DNS .............7 5.3. Does your solution require centralized registration? .......8 5.4. Have you checked for DNS circular dependencies? ............8 5.5. What if a DNS server itself is multihomed? .................8 5.6. What additional load will be placed on DNS servers? ........8 5.7. Any upstream provider support required? ....................8 5.8. How do you debug connectivity? .............................8 6. Application Concerns and Backward Compatibility .................8 6.1. What application/API changes are needed? ...................8 6.2. Is this solution backward compatible with "old" IP version 6? .................................................9 6.3. Is your solution backward compatible with IPv4? ............9 6.4. Can IPv4 devices take advantage of this solution? ..........9 6.5. What is the impact of your solution on different types of sites? ............................................9 6.6. How will your solution interact with other middleboxes? ...10 6.7. Referrals .................................................10 6.8. Demonstrate use with a real life complex application ......10 7. Legal Concerns .................................................10 8. Security Considerations ........................................10 9. Acknowledgements ...............................................11 10. References ....................................................11 10.1. Normative References .....................................11 10.2. Informative References ...................................11 At the time of this writing there are quite a number of proposed solutions to the problem of multihoming within IPv6, and related problems such as the locator/identifier split. This document contains several sets of questions that attempt to focus these solutions on operational problems. This document does not suggest methods to solve the problem. Rather, we simply want to ensure that while solving a problem the medicine is not worse than the cure. We focus on practical operational problems that both single-homed and multihomed deployments may face. 2.1. How will your solution solve the multihoming problem? 2.7. Can multihoming capabilities be negotiated end-to-end during a connection? One of the significant goals of IPv4 multihoming solutions has been the ability to perform traffic engineering based on appropriately adjusting the BGP advertisements. If the prefixes used by such sites was be aggregated (particularly beyond the site"s border), the site"s ability to perform traffic engineering would be diminished. 5.5. What if a DNS server itself is multihomed? There are several possible approaches. For instance, a multihoming service could attempt to require no changes to the API, in which case it is possible that IP addresses might become opaque blobs that work with the API, but might break operational assumptions that applications make about addresses. Consider the case of a web server that wants to log IP addresses. How will it accomplish this task? Does your solution impose requirements on non-multihomed/non-mobile hosts? o single homed sites o small multihomed sites o large multihomed sites o ad-hoc sites o short lived connections (think aggregator wireless ISPs) Provide a detailed walk-through of SIP + Real Time Streaming Protocol (SIP+RTSP) when one or several of the peers are multihomed. How does your analysis change when encrypted RTSP is used or when SIP with S/MIME end-to-end (e2e) signalling is used? [2] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [4] Nordmark, E., "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. http://www.ietf.org/rfc/rfc4225.txt 4225 Mobile IP Version 6 Route Optimization Security Design Background. P. Nikander, J. Arkko, T. Aura, G. Montenegro, E. Nordmark. December 2005. (Format: TXT=3D98584 bytes) (Status: INFORMATIONAL) [5] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4274.txt 4274 BGP-4 Protocol Analysis. D. Meyer, K. Patel. January 2006. (Format: TXT=3D38200 bytes) (Status: INFORMATIONAL) One can easily construct sets of policies for which BGP cannot guarantee that stable routings are unique. This is illustrated by the following simple example. Consider four Autonomous Systems, AS1, AS2, AS3, and AS4. AS1 and AS2 are peers, and they provide transit for AS3 and AS4, respectively. Suppose AS3 provides transit for AS4 (in this case AS3 is a customer of AS1, and AS4 is a multihomed customer of both AS3 and AS2). AS4 may want to use the link to AS3 as a "backup" link, and sends AS3 a community value that AS3 has configured to lower the preference of AS4's routes to a level below that of its upstream provider, AS1. The intended "backup routing" to AS4 is illustrated here: http://www.ietf.org/rfc/rfc4336.txt 4336 Problem Statement for the Datagram Congestion Control Protocol (DCCP). S. Floyd, M. Handley, E. Kohler. March 2006. (Format: TXT=3D53585 bytes) (Status: INFORMATIONAL) One could suggest adding support for alternative congestion control mechanisms as an option to SCTP, and adding a fully-unreliable variant that does not include the mechanisms for multiple streams. We would argue against this. SCTP is well-suited for applications that desire limited retransmission with multistream or multihoming support. Adding support for fully-unreliable variants, multiple congestion control profiles, and reduced single-stream headers would risk introducing unforeseen interactions and make further o Mobility: Mechanisms for multihoming and mobility are one area of additional functionality that cannot necessarily be layered cleanly and effectively on top of a transport protocol. Thus, one outstanding design decision with any new transport protocol concerns whether to incorporate mechanisms for multihoming and mobility into the protocol itself. The current version of DCCP [RFC4340] includes no multihoming or mobility support. http://www.ietf.org/rfc/rfc4460.txt 4460 Stream Control Transmission Protocol (SCTP) Specification Errata and Issues. R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M. Tuexen. April 2006. (Format: TXT=3D215405 bytes) (Status: INFORMATIONAL) The current retransmission policy (send all retransmissions an alternate destination) in the specification has performance issues under certain loss conditions with multihomed endpoints. Instead, fast retransmissions should be sent to the same destination, and only timeout retransmissions should be sent to an alternate destination [4]. [4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for End-to-end Failover with Transport Layer Multihoming", GLOBECOM, November 2004., . http://www.ietf.org/rfc/rfc4472.txt 4472 Operational Considerations and Issues with IPv6 DNS. A. Durand, J. Ihren, P. Savola. April 2006. (Format: TXT=3D68882 bytes) = (Status: INFORMATIONAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4477.txt 4477 Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues. T. Chown, S. Venaas, C. Strauf. May 2006. = (Format: TXT=3D30440 bytes) (Status: INFORMATIONAL) There is a general multihoming issue to be solved for DHCP. A host might simultaneously be connected to multiple networks managed by multiple parties. Also, IPv4 and IPv6 might be managed by separate parties. While these issues are touched on in this document, here we focus on the specific issues for operating DHCP in a mixed (typically dual-stack) IPv4 and IPv6 environment within a single administrative domain. It has been noted from comments that the first four, and possibly five, subsections here may also be viewed as multihoming issues. As a footnote, we note that this work has overlap with multihoming and multi-interface configuration issues. It is also interwoven with the Detecting Network Attachment area, for example, where a node may move from an IPv4-only network to a dual-stack network, or vice versa. Both aspects may be best abstracted for discussion and progression in the respective IETF multi6, shim6, and dna WGs, in parallel with the two-server progression in the dhc WG. http://www.ietf.org/rfc/rfc4555.txt 4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE). P. Eronen. June 2006. (Format: TXT=3D78698 bytes) (Status: PROPOSED STANDARD) IKEv2 Mobility and Multihoming Protocol (MOBIKE) This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. There are scenarios where these IP addresses might change. One example is mobility: a host changes its point of network attachment and receives a new IP address. Another example is a multihoming host that would like to change to a different interface if, for instance, the currently used interface stops working for some reason. MOBIKE allows both parties to be multihomed; however, only one pair of addresses is used for an SA at a time. In particular, load balancing is beyond the scope of this specification. Another protocol run in a multihoming scenario is illustrated below. In this scenario, the initiator has one address but the responder has two. [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and Multihoming Extensions for IKEv2 (SMOBIKE)", Work in Progress, March 2004. http://www.ietf.org/rfc/rfc4577.txt 4577 OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P. Psenak, P. Pillay-Esnault. June 2006. (Format: TXT=3D61515 bytes) (Updates RFC4364) (Status: PROPOSED STANDARD) It is possible to treat these two sites as a single VPN site that just happens to be multihomed to the backbone. This is in fact the simplest thing to do and is perfectly adequate, provided that the preferred route between the two sites is via the intra-area OSPF link (a "backdoor link"), rather than via the VPN backbone. There will be routes between sites that go through the PE routers, but these routes will appear to be inter-area routes, and OSPF will consider them less preferable than the intra-area routes through the backdoor link. Note that this way of handling external routes makes every PE appear to be an ASBR attached to all the external routes. In a multihomed site, this can result in a number of type 5 LSAs containing the same information. http://www.ietf.org/rfc/rfc4609.txt 4609 Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements. P. Savola, R. Lehtonen, = D. Meyer. October 2006. (Format: TXT=3D49812 bytes) (Status: INFORMATIONAL) [14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4621.txt 4621 Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol. T. Kivinen, H. Tschofenig. August 2006. (Format: TXT=3D73070 bytes) (Status: INFORMATIONAL) Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol The IKEv2 Mobility and Multihoming (MOBIKE) protocol is an extension of the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). 1. Introduction ....................................................3 2. Terminology .....................................................4 3. Scenarios .......................................................6 3.1. Mobility Scenario ..........................................6 3.2. Multihoming Scenario .......................................7 3.3. Multihomed Laptop Scenario .................................8 4. Scope of MOBIKE .................................................8 5. Design Considerations ..........................................10 5.1. Choosing Addresses ........................................10 5.1.1. Inputs and Triggers ................................11 5.1.2. Connectivity .......................................11 5.1.3. Discovering Connectivity ...........................12 5.1.4. Decision Making ....................................12 5.1.5. Suggested Approach .................................12 5.2. NAT Traversal (NAT-T) .....................................12 5.2.1. Background and Constraints .........................12 5.2.2. Fundamental Restrictions ...........................13 5.2.3. Moving behind a NAT and Back .......................13 5.2.4. Responder behind a NAT .............................14 5.2.5. NAT Prevention .....................................15 5.2.6. Suggested Approach .................................15 5.3. Scope of SA Changes .......................................15 5.4. Zero Address Set Functionality ............................16 5.5. Return Routability Check ..................................17 5.5.1. Employing MOBIKE Results in Other Protocols ........19 5.5.2. Return Routability Failures ........................20 5.5.3. Suggested Approach .................................21 5.6. IPsec Tunnel or Transport Mode ............................22 6. Protocol Details ...............................................22 6.1. Indicating Support for MOBIKE .............................22 6.2. Path Testing and Window size ..............................23 6.3. Message Presentation ......................................24 6.4. Updating Address Set ......................................25 7. Security Considerations ........................................26 8. Acknowledgements ...............................................26 9. References .....................................................27 9.1. Normative references ......................................27 9.2. Informative References ....................................27 3.2. Multihoming Scenario Figure 2: Multihoming Scenario 3.3. Multihomed Laptop Scenario Getting mobility and multihoming actually working requires many different components to work together, including coordinating decisions between different layers, different mobility mechanisms, and IPsec/IKEv2. Most of those aspects are beyond the scope of MOBIKE: MOBIKE focuses only on what two peers need in order to agree at the IKEv2 level (like new message formats and some aspects of their processing) required for interoperability. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [WIP-Ark06] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, June 2006. [WIP-Nik06] Nikander, P., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006. http://www.ietf.org/rfc/rfc4632.txt 4632 Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan. V. Fuller, T. Li. August 2006. (Format: TXT=3D66944 bytes) (Obsoletes RFC1519) (Also BCP0122) = (Status: BEST CURRENT PRACTICE) [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. http://www.ietf.org/rfc/rfc4651.txt 4651 A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization. C. Vogt, J. Arkko. February 2007. (Format: TXT=3D79226 bytes) (Status: INFORMATIONAL) [22] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, June 2006. [39] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [43] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4778.txt 4778 Operational Security Current Practices in Internet Service Provider Environments. M. Kaeo. January 2007. (Format: TXT=3D88344 bytes) (Status: INFORMATIONAL) Routing filters are used to control the flow of routing information. In IPv6 networks, some providers are liberal in accepting /48s due to the still unresolved multihoming issues, while others filter at allocation boundaries, which are typically at /32. Any announcement received that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing is filtered out of eBGP. Note that this is for non-customer traffic. Most ISPs will accept any agreed upon prefix length from its customer(s). [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4779.txt 4779 ISP IPv6 Deployment Scenarios in Broadband Access Networks. S. Asadullah, A. Ahmed, C. Popoviciu, P. Savola, J. Palet. January = 2007. (Format: TXT=3D188511 bytes) (Status: INFORMATIONAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4786.txt 4786 Operation of Anycast Services. J. Abley, K. Lindqvist. December 2006. (Format: TXT=3D56818 bytes) (Also BCP0126) (Status: BEST = CURRENT PRACTICE) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4830.txt 4830 Problem Statement for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT=3D29815 bytes) (Status: INFORMATIONAL) First, new IETF work on global mobility management protocols that are not Mobile IPv6, such as Host Identity Protocol (HIP) [16] and IKEv2 Mobility and Multihoming (MOBIKE) [4], suggests that future wireless IP nodes may support a more diverse set of global mobility protocols. While it is possible that existing localized mobility management protocols could be used with HIP and MOBIKE, some would require additional effort to implement, deploy, or in some cases, even specify in a non-Mobile IPv6 mobile environment. [4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc4831.txt 4831 Goals for Network-Based Localized Mobility Management (NETLMM). J. Kempf, Ed.. April 2007. (Format: TXT=3D35232 bytes) (Status: INFORMATIONAL) Identity Protocol (HIP) [11] and IKEv2 Mobility and Multihoming (MOBIKE) [6] are likely to need support in addition to Mobile IPv6 [9], and Mobile IPv4 [12] support may also be necessary. [6] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc4843.txt 4843 An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID). P. Nikander, J. Laganier, F. Dupont. April 2007. (Format: TXT=3D32483 bytes) (Status: EXPERIMENTAL) Typical benefits from overlay routing include location independence, more scalable multicast, anycast, and multihoming support than in IP, and better DoS resistance than in the vanilla Internet. The main drawback is typically an order of magnitude of slower performance, caused by an easily largish number of extra look-up or forwarding steps needed. Consequently, in most practical cases, the overlay routing system is used only during initial protocol state set-up (cf. TCP handshake), after which the communicating endpoints exchange packets directly with IP, bypassing the overlay network. http://www.ietf.org/rfc/rfc4852.txt 4852 IPv6 Enterprise Network Analysis - IP Layer 3 Focus. J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green. April 2007. (Format: TXT=3D76199 bytes) (Status: INFORMATIONAL) - Multihoming - Application transition/porting (see [APPS]). - IPv6 VPN, firewall, or intrusion detection deployment. - IPv6 network management and QoS deployment. - Detailed IT Department requirements. - Deployment of novel IPv6 services, e.g., Mobile IPv6. - Requirements or Transition at the Providers' network. - Transport protocol selection for applications with IPv6. - Application layer and configuration issues. - IPv6 only future deployment scenarios. Most of these are discussed in Section 4 of [BSCN]. Here we comment on those aspects that we believe are in scope for this analysis document. Thus, we have not included network management, multihoming, multicast, or application transition analysis here; however, these aspects should be addressed in Stage 2. http://www.ietf.org/rfc/rfc4861.txt 4861 Neighbor Discovery for IP version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson, H. Soliman. September 2007. (Format: = TXT=3D235106 bytes) (Obsoletes RFC2461) (Updated by RFC5942) (Status: DRAFT STANDARD) 7. Address Resolution and Neighbor Unreachability Detection .......59 7.1. Message Validation ........................................59 7.1.1. Validation of Neighbor Solicitations ...............59 7.1.2. Validation of Neighbor Advertisements ..............60 7.2. Address Resolution ........................................60 7.2.1. Interface Initialization ...........................61 7.2.2. Sending Neighbor Solicitations .....................61 7.2.3. Receipt of Neighbor Solicitations ..................62 7.2.4. Sending Solicited Neighbor Advertisements ..........63 7.2.5. Receipt of Neighbor Advertisements .................64 7.2.6. Sending Unsolicited Neighbor Advertisements ........66 7.2.7. Anycast Neighbor Advertisements ....................67 7.2.8. Proxy Neighbor Advertisements ......................68 7.3. Neighbor Unreachability Detection .........................68 7.3.1. Reachability Confirmation ..........................69 7.3.2. Neighbor Cache Entry States ........................70 7.3.3. Node Behavior ......................................71 8. Redirect Function ..............................................73 8.1. Validation of Redirect Messages ...........................74 8.2. Router Specification ......................................75 8.3. Host Specification ........................................76 9. Extensibility - Option Processing ..............................76 10. Protocol Constants ............................................78 11. Security Considerations .......................................79 11.1. Threat Analysis ..........................................79 11.2. Securing Neighbor Discovery Messages .....................81 12. Renumbering Considerations ....................................81 13. IANA Considerations ...........................................83 14. References ....................................................84 14.1. Normative References .....................................84 14.2. Informative References ...................................84 Appendix A: Multihomed Hosts ......................................87 Appendix B: Future Extensions .....................................88 Appendix C: State Machine for the Reachability State ..............89 Appendix D: Summary of IsRouter Rules .............................91 Appendix E: Implementation Issues .................................92 Appendix F: Changes from RFC 2461 .................................94 Acknowledgments ...................................................95 Prefix Information These options specify the prefixes that are on-link and/or are used for stateless address autoconfiguration. A router SHOULD include all its on-link prefixes (except the link-local prefix) so that multihomed hosts have complete prefix information about on-link destinations for the links to which they attach. If complete information is lacking, a host with multiple interfaces may not be able to choose the correct outgoing interface when sending traffic to its neighbors. This model is only concerned with the aspects of host behavior directly related to Neighbor Discovery. In particular, it does not concern itself with such issues as source address selection or the selecting of an outgoing interface on a multihomed host. Routers and multihomed hosts have multiple interfaces. The remainder of this document assumes that all sent and received Neighbor Discovery messages refer to the interface of appropriate context. For example, when responding to a Router Solicitation, the corresponding Router Advertisement is sent out the interface on which the solicitation was received. Appendix A: Multihomed Hosts There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. Implementors are encouraged to experiment with various approaches to making Neighbor Discovery work on multihomed hosts and to report their experiences. Further work related to this problem can be found in [RTSEL]. If a multihomed host receives Router Advertisements on all of its interfaces, it will (probably) have learned on-link prefixes for the addresses residing on each link. When a packet must be sent through a router, however, selecting the "wrong" router can result in a suboptimal or non-functioning path. There are number of issues to consider: 1) In order for a router to send a redirect, it must determine that the packet it is forwarding originates from a neighbor. The standard test for this case is to compare the source address of the packet to the list of on-link prefixes associated with the interface on which the packet was received. If the originating host is multihomed, however, the source address it uses may belong to an interface other than the interface from which it was sent. In such cases, a router will not send redirects, and suboptimal routing is likely. In order to be redirected, the sending host must always send packets out the interface corresponding to the outgoing packet's source address. Note that this issue never arises with non-multihomed hosts; they only have one interface. Additional discussion on this topic can be found in RFC 1122 under Section 3.3.4.2. 2) If the selected first-hop router does not have a route at all for the destination, it will be unable to deliver the packet. However, the destination may be reachable through a router on one of the other interfaces. Neighbor Discovery does not address this scenario; it does not arise in the non-multihomed case. 3) Even if the first-hop router does have a route for a destination, there may be a better route via another interface. No mechanism exists for the multihomed host to detect this situation. If a multihomed host fails to receive Router Advertisements on one or more of its interfaces, it will not know (in the absence of configured information) which destinations are on-link on the affected interface(s). This leads to the following problem: If Router Advertisements are received on some, but not all, interfaces, a multihomed host could choose to only send packets out on the interfaces on which it has received Router Advertisements. A key assumption made here, however, is that routers on those other interfaces will be able to route packets to the ultimate destination, even when those destinations reside on the subnet to which the sender connects, but has no on-link prefix information. Should the assumption be FALSE, communication would fail. Even if the assumption holds, packets will traverse a suboptimal path. http://www.ietf.org/rfc/rfc4862.txt 4862 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten, T. Jinmei. September 2007. (Format: TXT=3D72482 bytes) (Obsoletes RFC2462) (Status: DRAFT STANDARD) Autoconfiguration is performed on a per-interface basis on multicast- capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. Autoconfiguration applies primarily to hosts, with two exceptions. Routers are expected to generate a link-local address using the procedure outlined below. In addition, routers perform Duplicate Address Detection on all addresses prior to assigning them to an interface. http://www.ietf.org/rfc/rfc4864.txt 4864 Local Network Protection for IPv6. G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT=3D95448 = bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Perceived Benefits of NAT and Its Impact on IPv4 . . . . . . . 6 2.1. Simple Gateway between Internet and Private Network . . . 6 2.2. Simple Security Due to Stateful Filter Implementation . . 6 2.3. User/Application Tracking . . . . . . . . . . . . . . . . 7 2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 8 2.5. Independent Control of Addressing in a Private Network . . 9 2.6. Global Address Pool Conservation . . . . . . . . . . . . . 9 2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 10 3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 11 3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 11 3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 12 3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13 3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13 4. Using IPv6 Technology to Provide the Market Perceived Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Simple Gateway between Internet and Internal Network . . . 14 4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15 4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17 4.4. Privacy and Topology Hiding Using IPv6 . . . . . . . . . . 17 4.5. Independent Control of Addressing in a Private Network . . 20 4.6. Global Address Pool Conservation . . . . . . . . . . . . . 21 4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Medium/Large Private Networks . . . . . . . . . . . . . . 22 5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 24 5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25 5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 26 6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 27 6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 27 6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 28 6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 28 6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. Informative References . . . . . . . . . . . . . . . . . . . . 30 Appendix A. Additional Benefits Due to Native IPv6 and Universal Unique Addressing . . . . . . . . . . . . . 32 A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 32 A.2. Auto-Configuration . . . . . . . . . . . . . . . . . . . . 32 A.3. Native Multicast Services . . . . . . . . . . . . . . . . 33 A.4. Increased Security Protection . . . . . . . . . . . . . . 33 A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34 A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 34 Goal IPv4 IPv6 +------------------+-----------------------+-----------------------+ | Simple Gateway | DHCP - single | DHCP-PD - arbitrary | | as default router| address upstream | length customer | | and address pool | DHCP - limited | prefix upstream | | manager | number of individual | SLAAC via RA | | | devices downstream | downstream | | | see Section 2.1 | see Section 4.1 | +------------------|-----------------------|-----------------------+ | Simple Security | Filtering side | Explicit Context | | | effect due to lack | Based Access Control | | | of translation state | (Reflexive ACL) | | | see Section 2.2 | see Section 4.2 | +------------------|-----------------------|-----------------------+ | Local Usage | NAT state table | Address uniqueness | | Tracking | | | | | see Section 2.3 | see Section 4.3 | +------------------|-----------------------|-----------------------+ | End-System | NAT transforms | Temporary use | | Privacy | device ID bits in | privacy addresses | | | the address | | | | see Section 2.4 | see Section 4.4 | +------------------|-----------------------|-----------------------+ | Topology Hiding | NAT transforms | Untraceable addresses| | | subnet bits in the | using IGP host routes| | | address | /or MIPv6 tunnels | | | see Section 2.4 | see Section 4.4 | +------------------|-----------------------|-----------------------+ | Addressing | RFC 1918 | RFC 3177 & 4193 | | Autonomy | see Section 2.5 | see Section 4.5 | +------------------|-----------------------|-----------------------+ | Global Address | RFC 1918 | 17*10^18 subnets | | Pool | << 2^48 application | 3.4*10^38 addresses | | Conservation | end points | full port list / addr | | | topology restricted | unrestricted topology | | | see Section 2.6 | see Section 4.6 | +------------------|-----------------------|-----------------------+ | Renumbering and | Address translation | Preferred lifetime | | Multihoming | at border | per prefix & multiple| | | | addresses per | | | | interface | | | see Section 2.7 | see Section 4.7 | +------------------+-----------------------+-----------------------+ 2.7. Multihoming and Renumbering with NAT Allowing a network to be multihomed and renumbering a network are quite different functions. However, these are argued together as reasons for using NAT, because making a network multihomed is often a transitional state required as part of network renumbering, and NAT interacts with both in the same way. For enterprise networks, it is highly desirable to provide resiliency and load-balancing to be connected to more than one Internet Service Provider (ISP) and to be able to change ISPs at will. This means that a site must be able to operate under more than one Classless Inter-Domain Routing (CIDR) prefix [18] and/or readily change its CIDR prefix. Unfortunately, IPv4 was not designed to facilitate either of these maneuvers. However, if a site is connected to its ISPs via NAT boxes, only those boxes need to deal with multihoming and renumbering issues. 4.7. Multihoming and Renumbering IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR-allocated prefixes, and thus with several simultaneous ISPs. An address selection mechanism [11] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in regard to multiple addresses therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and the processes for adding, removing, and renumbering active prefixes at a site have been documented in [16] and [21]. However, multihoming and renumbering remain technically challenging even with IPv6 with regards to session continuity across multihoming events or interactions with ingress filtering (see the Gap Analysis below). 6.4. Site Multihoming This complex problem has never been completely solved for IPv4, which is exactly why NAT has been used as a partial solution. For IPv6, after several years of work, the IETF has converged on an architectural approach intended with service restoration as initial aim [22]. When this document was drafted, the IETF was actively defining the details of this approach to the multihoming problem. The approach appears to be most suitable for small and medium sites, though it will conflict with existing firewall state procedures. At this time, there are also active discussions in the address http://www.ietf.org/rfc/rfc4885.txt 4885 Network Mobility Support Terminology. T. Ernst, H-Y. Lach. July 2007. (Format: TXT=3D37967 bytes) (Status: INFORMATIONAL) 4.4. Sub-NEMO . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Root-MR . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Parent-MR . . . . . . . . . . . . . . . . . . . . . . . . 10 4.7. Sub-MR . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.8. Depth . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Multihoming Terms . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Multihomed Host or MNN . . . . . . . . . . . . . . . . . . 11 5.2. Multihomed Mobile Router . . . . . . . . . . . . . . . . . 11 5.3. Multihomed Mobile Network (multihomed-NEMO) . . . . . . . 12 5.4. Nested Multihomed Mobile Network . . . . . . . . . . . . . 12 5.5. Split-NEMO . . . . . . . . . . . . . . . . . . . . . . . . 12 5.6. Illustration . . . . . . . . . . . . . . . . . . . . . . . 12 6. Home Network Model Terms . . . . . . . . . . . . . . . . . . . 14 6.1. Home Link . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Home Network . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Home Address . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Mobile Home Network . . . . . . . . . . . . . . . . . . . 14 6.5. Distributed Home Network . . . . . . . . . . . . . . . . . 14 6.6. Mobile Aggregated Prefix . . . . . . . . . . . . . . . . . 15 6.7. Aggregated Home Network . . . . . . . . . . . . . . . . . 15 6.8. Extended Home Network . . . . . . . . . . . . . . . . . . 15 6.9. Virtual Home Network . . . . . . . . . . . . . . . . . . . 15 7. Mobility Support Terms . . . . . . . . . . . . . . . . . . . . 15 7.1. Host Mobility Support . . . . . . . . . . . . . . . . . . 15 7.2. Network Mobility Support (NEMO Support) . . . . . . . . . 15 7.3. NEMO Basic Support . . . . . . . . . . . . . . . . . . . . 15 7.4. NEMO Extended Support . . . . . . . . . . . . . . . . . . 16 7.5. NEMO Routing Optimization (NEMO RO) . . . . . . . . . . . 16 7.6. MRHA Tunnel . . . . . . . . . . . . . . . . . . . . . . . 16 7.7. Pinball Route . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 Section 2 introduces terms to define the architecture, while terms needed to emphasize the distinct functionalities of those architectural components are described in Section 3. Section 4, Section 5, and Section 6 describe terms pertaining to nested mobility, multihoming, and different configurations of mobile networks at home, respectively. The different types of mobility are defined in Section 7. The last section lists miscellaneous terms that do not fit into any other section. 5. Multihoming Terms Multihoming, as currently defined by the IETF, covers site- multihoming [9] and host multihoming. We enlarge this terminology to include "multihomed mobile router" and "multihomed mobile network". The specific configurations and issues pertaining to multihomed mobile networks are covered in [10]. 5.1. Multihomed Host or MNN A host (e.g., an MNN) is multihomed when it has several addresses to choose between, i.e., in the following cases when it is: 5.2. Multihomed Mobile Router =46rom the definition of a multihomed host, it follows that a mobile router is multihomed when it has several addresses to choose between, i.e., in the following cases when the MR is: Figure 6: Multihoming: MR with multiple E-faces 5.3. Multihomed Mobile Network (multihomed-NEMO) A mobile network is multihomed when a MR is multihomed or there are multiple MRs to choose between (see the corresponding analysis in [10]). Figure 7: Multihoming: NEMO with Multiple MRs 5.4. Nested Multihomed Mobile Network A nested mobile network is multihomed when either a root-MR is multihomed or there are multiple root-MRs to choose between. Figure 6 and Figure 7 show two examples of multihomed mobile networks. Figure 8 shows two independent mobile networks. NEMO-1 is single-homed to the Internet through MR1. NEMO-2 is multihomed to the Internet through MR2a and MR2b. Both mobile networks offer access to visiting nodes and networks through an AR. * NEMO-2 is still multihomed to the Internet through AR1 and ARz * The aggregated nested mobile network is not multihomed, since NEMO-2 cannot be used as a transit network for NEMO-1 * NEMO-1 is not multihomed * The aggregated nested mobile network is multihomed Figure 8: Nested Multihomed NEMO [9] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [10] Ng, C-W., Paik, E-K., Ernst, T., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", Work in Progress, February 2007. http://www.ietf.org/rfc/rfc4886.txt 4886 Network Mobility Support Goals and Requirements. T. Ernst. July 2007. (Format: TXT=3D29083 bytes) (Status: INFORMATIONAL) To complete these tasks, the NEMO working group has decided to take a stepwise approach. The steps in this approach include standardizing a basic solution to preserve session continuity (NEMO Basic Support, see [3]) and studying the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (NEMO Extended Support, see [6] and [7] for a discussion on routing optimization issues and [8] for a discussion on multihoming issues). However, the working group is not chartered to actually standardize a solution for Extended Support at this point in time. If deemed necessary, the working group will be rechartered based on the conclusions of the discussions. network is multihomed and is itself a multi-level aggregation of mobile networks with collectively thousands of mobile routers and hosts. While the list of potential configurations of mobile networks cannot be limited, at least the following ones are desirable: o Multihomed mobile network: either when a single MR has multiple attachments to the internet, or when the mobile network is attached to the Internet by means of multiple MRs (see definition in [1] and the analysis in [8]). Mobile networks and mobile nodes owned by different administrative entities are expected to be displaced within a domain boundary or between domain boundaries. Multihoming, vertical and horizontal handoffs, and access control mechanisms are desirable to achieve this goal. Such mobility is not expected to be limited for any consideration other than administrative and security policies. R12: The solution must function for multihomed MRs and multihomed mobile networks as defined in [1]. [8] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", Work in Progress), February 2007. http://www.ietf.org/rfc/rfc4887.txt 4887 Network Mobility Home Network Models. P. Thubert, R. Wakikawa, V. Devarapalli. July 2007. (Format: TXT=3D40372 bytes) (Status: INFORMATIONAL) Also, note that NEMO authorizes multiple registrations for a same MNP by different Mobile Routers. This is a case of multihoming, and it normally means that the Mobile Routers are interconnected by the Ingress network that bears the common MNP. But there is no provision in NEMO Basic Support to test that this condition is met at binding time and maintained over time. Making the Home Link virtual bars the deployment of multiple Home Agents, which may be desirable for reasons of load balancing. Please refer to the NEMO multihoming issues [9] for more on this. [9] Ng, C., "Analysis of Multihoming in Network Mobility Support", Work in Progress, February 2007. http://www.ietf.org/rfc/rfc4889.txt 4889 Network Mobility Route Optimization Solution Space Analysis. C. Ng, F. Zhao, M. Watari, P. Thubert. July 2007. (Format: TXT=3D95880 bytes) (Status: INFORMATIONAL) [45] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", Work in Progress, March 2007. http://www.ietf.org/rfc/rfc4891.txt 4891 Using IPsec to Secure IPv6-in-IPv4 Tunnels. R. Graveman, M. Parthasarathy, P. Savola, H. Tschofenig. May 2007. (Format: = TXT=3D46635 bytes) (Status: INFORMATIONAL) In Appendix A, we also explore what it would take to use so-called Specific SPD (SSPD) tunnel mode. Such usage is more complicated because IPv6 prefixes need to be known a priori, and multicast and link-local traffic do not work over such a tunnel. Fragment handling in tunnel mode is also more difficult. However, because the Mobility and Multihoming Protocol (MOBIKE) [RFC4555] supports only tunnel mode, when the IPv4 endpoints of a tunnel are dynamic and the other constraints are not applicable, using tunnel mode may be an acceptable solution. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc4908.txt 4908 Multi-homing for small scale fixed network Using Mobile IP and NEMO. K. Nagami, S. Uda, N. Ogashiwa, H. Esaki, R. Wakikawa, H. Ohnishi. June 2007. (Format: TXT=3D20230 bytes) (Status: = EXPERIMENTAL) Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO) RFC 4908 Multihoming for Fixed Network June 2007 Multihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy. Users of small-scale networks need an easy method to improve network availability and to load balance several links. Multihoming technology is one of the solutions to improve availability. Conventional major multihoming networks use BGP, but it has some issues. Therefore, we propose a multihoming architecture using mobile IP [1] and NEMO [2] for small-scale fixed networks. 1.1. General Benefits of Multihoming In a multihoming network environment, both users and network managers benefit from controlling outgoing traffic, incoming traffic, or both of them. Those benefits are described in "Goals and Benefits of Multihoming" [3]. The following is a summary of those goals and benefits: 1.2. Problems to be Solved to Accomplish Multihoming Several multihoming technologies have been proposed so far. Conventional major multihoming networks use BGP, but it has some issues, as follows. RFC 4908 Multihoming for Fixed Network June 2007 In the multihoming environments, each user's network needs to advertise its address block to all ISPs connected to them. If a multihomed user connects to only one ISP, the ISP can advertise routing information to aggregate them. But some multihomed users need to connect with different ISPs to be prepared for ISP failure. In this case, ISPs need to advertise routing information for multihomed users without aggregation. Therefore, the number of routing entries in the Internet is increasing one by one. It is not easy to control incoming traffic in the case of the conventional multihoming architecture using BGP. Therefore, load balancing of connected links is difficult. 2. Multihoming Architecture Using Mobile IP and NEMO By their nature, NEMO and mobile IP must work with multihoming. This is because mobile nodes need to use multiple links to improve the availability of network connectivity since the wireless link is not always stable. Therefore, we propose that multihoming for fixed nodes (routers and hosts) uses the framework of NEMO and mobile IP. 2.2. Overview of Multihoming Network Architecture Using Mobile IP Figure 1 shows the basic multihoming network architecture. In this architecture, a mobile router (MR), which is a border router of the multihomed network, sets up several tunnels between the MR and the HA by multiple-CoA registration. An HA (or a router to which the HA RFC 4908 Multihoming for Fixed Network June 2007 belongs) advertises the user's network prefix (Prefix X in Figure 1) to ISPs via the routing protocol. If the HA has several multihomed networks (Prefix X and Y in Figure 1), they can advertise an aggregated network prefix to ISPs. Therefore, the Internet routing entries do not increase one by one when the number of multihomed users is increased. HA1 ||(Advertise aggregated prefix X and Y) |v ISP | +------------------------+---------------------+ | The Internet | +-+----------+--------------------+----------+-+ | | | | ISP-A ISP-B ISP-A' ISP-B' | | | | | | | | +--- MR ---+ +--- MR ---+ CoA1 | CoA2 CoA1|CoA2 | | -------+--------- (Prefix X) -------+------ (Prefix Y) Multihomed Network X Multihomed Network Y Packets to multihomed users go to the HA, and the HA sends packets to the MR using CoA1 and CoA2. The HA selects a route in which a CoA is used. The route selection algorithm is out for scope of this document. This can improve the availability of the user network and control traffic going from the ISP to the MR. In the basic architecture, HA1 is the single point of failure. In order to improve the availability of the user network, multiple HAs are needed. This is described in Section 3.2. RFC 4908 Multihoming for Fixed Network June 2007 HA1 ^ | | (1) Packets to prefix X | | | (2) HA forwards the packets are sent to HA | | v to CoA1 or CoA2 +-------+------+ | The Internet | +-+----------+-+ | | | | |(3) Packets are forwarded over | | | the MIP tunnel selected by | | v the HA1 ISP-A ISP-B | | | | | | +--- MR ---+ v CoA1 | CoA2 | -------+--------- (Prefix X) Multihomed Network A RFC 4908 Multihoming for Fixed Network June 2007 sync HA1 ------ HA2 | | +-+----------+-+ | The Internet | +-+----------+-+ | | ISP-A ISP-B | | | | +--- MR ---+ CoA1 | CoA2 | -------+--------- Multihomed Network The multihomed architecture proposed in this document is basically the same as the architecture of NEMO. Furthermore, NEMO protocols meet the requirements of the proposed architecture in this document, which are: The proposed multihomed architecture uses NEMO protocols as one of the applications of NEMO. Needless to say, using the NEMO protocol is one of the solutions to accomplish the proposed multihome RFC 4908 Multihoming for Fixed Network June 2007 In the proposed architecture, the xSP (Multihomed Service Provider) is introduced. The xSP is a conceptual service provider; it doesn't have to be connected to the Internet physically for all practical purposes. xSP has one or more aggregatable mobile network prefixes. xSP contracts with some ISPs that are physically connected to the Internet. The purpose of this contract is to set up some HAs in those ISPs' networks. Those HAs announce the xSP's aggregated mobile network prefixes. This means that HAs work just like border gateway routers, and this situation is the same as peering between the ISP and xSP. In this case, the origin Autonomous System (AS) announced from the HAs is the xSP. On the other hand, a multihomed user (a small office user or home user) contracts with the xSP to acquire a mobile network prefix from the xSP. Each multihomed user has an MR and multiple L3 connectivity to the Internet via multiple ISPs, and the MR will establish multiple tunnels to the HA. Since the user's mobile network prefixes are aggregated and announced from the HA, the packets to the user's mobile network will be sent to the nearest HA depending on global routing information at that time. The HA that received such packets will forward them to the user's network over the established multiple tunnels. RFC 4908 Multihoming for Fixed Network June 2007 This document describes requirements of multiple CoAs and HAs for redundancy. It is necessary to enhance the protocols of MIP and NEMO to solve the requirements. Security considerations of these multihoming networks must be considered in a specification of each protocol. [3] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, "Goals and Benefits of Multihoming", Work in Progress, February 2004. RFC 4908 Multihoming for Fixed Network June 2007 RFC 4908 Multihoming for Fixed Network June 2007 http://www.ietf.org/rfc/rfc4925.txt 4925 Softwire Problem Statement. X. Li, Ed., S. Dawkins, Ed., D. Ward, Ed., A. Durand, Ed.. July 2007. (Format: TXT=3D49299 bytes) = (Status: INFORMATIONAL) o Relation of the softwire protocols to other host mechanisms in the same layer of the network stack. Examples of mechanisms to consider are tunneling mechanisms, VPNs (Virtual Private Networks), mobility, multihoming (SHIM6 (Level 3 Shim for IPv6)),... http://www.ietf.org/rfc/rfc4942.txt 4942 IPv6 Transition/Co-existence Security Considerations. E. Davies, S. Krishnan, P. Savola. September 2007. (Format: TXT=3D102878 = bytes) (Status: INFORMATIONAL) The addresses could be from the same network prefix (for example, privacy mechanisms [RFC4941] will periodically create new addresses taken from the same prefix, and two or more of these may be active at the same time), or from different prefixes (for example, when a network is multihomed, when for management purposes a node belongs to several subnets on the same link or is implementing anycast services). In all these cases, it is possible that a single host could be using several different addresses with different prefixes and/or different interface identifiers. It is desirable that the security administrator be able to identify that the same host is behind all these addresses. http://www.ietf.org/rfc/rfc4943.txt 4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful. S. Roy, A. Durand, J. Paugh. September 2007. (Format: TXT=3D16719 = bytes) (Status: INFORMATIONAL) APPENDIX A was modified to remove on-link assumption related text in bullet item 1) under the discussion on what happens when a multihomed host fails to receive Router Advertisements. http://www.ietf.org/rfc/rfc4948.txt 4948 Report from the IAB workshop on Unwanted Traffic March 9-10, 2006. L. Andersson, E. Davies, L. Zhang. August 2007. (Format: TXT=3D106199 bytes) (Status: INFORMATIONAL) Backbone networks in general are well-provisioned in regard to traffic capacities. Therefore, core routers and backbone link capacity do not get affected much by most DDoS attacks; a 5Gbps attack could be easily absorbed without causing noticeable impact on the performance of backbone networks. However, DDoS attacks often saturate access networks and make a significant impact on customers. In particular, multihomed customers who have multiple well- provisioned connections for high throughput and performance may suffer from aggregated DDoS traffic coming in from all directions. The IETF has also developed an additional set of recommendations extending BCP 38 to multihomed networks. These recommendations are published as BCP 84 [RFC3704]. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4953.txt 4953 Defending TCP Against Spoofing Attacks. J. Touch. July 2007. (Format: TXT=3D72756 bytes) (Status: INFORMATIONAL) [2] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc4966.txt 4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status. C. Aoun, E. Davies. July 2007. (Format: TXT=3D60284 bytes) (Obsoletes RFC2766) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . . 7 2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 7 2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 8 2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8 2.4. Loss of Information through Incompatible Semantics . . . . 9 2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 10 2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 11 2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 12 2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12 3. Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . 13 3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 13 3.2. Scalability and Single Point of Failure Concerns . . . . . 14 3.3. Issues with Lack of Address Persistence . . . . . . . . . 15 3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 16 4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16 4.1. Address Selection Issues when Communicating with Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16 4.2. Non-Global Validity of Translated RR Records . . . . . . . 18 4.3. Inappropriate Translation of Responses to A Queries . . . 19 4.4. DNS-ALG and Multi-Addressed Nodes . . . . . . . . . . . . 19 4.5. Limitations on Deployment of DNS Security Capabilities . . 19 5. Impact on IPv6 Application Development . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 23 * Interaction with SCTP and multihoming. 2.6. NAT-PT Interaction with SCTP and Multihoming However, SCTP also supports multihoming. During connection setup, SCTP control packets carry embedded addresses that would have to be translated. This would also require that the types of the options fields in the SCTP control packets be changed with consequent changes to packet length; the transport checksum would also have to be recalculated. The ramifications of multihoming as it might interact with NAT-PT have not been fully explored. Because of the 'chunked' nature of data transfer, it does not appear that that state would have to be maintained to relate packets transmitted using the different IP addresses associated with the connection. Even if these technical issues can be overcome, using SCTP in a NAT-PT environment may effectively nullify the multihoming advantages of SCTP if all the connections run through the same NAT-PT. The consequences of running a multihomed network with separate NAT-PT boxes associated with each of the 'homes' have not been fully explored, but one issue that will arise is described in Section 4.4. SCTP will need an associated "ALG" -- actually a Transport Layer Gateway -- to handle the packet payload modifications. If it turns out that that state is required, the state would have to be distributed and synchronized across several NAT-PT boxes in a multihomed environment. SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1. Many IPv6 nodes, especially in multihomed situations but also in single homed deployments, can expect to have multiple global addresses. The same may be true for multihomed IPv4 nodes. Responses to DNS queries for these nodes will normally contain all these addresses. Since the DNS-ALG in the NAT-PT has no knowledge which of the addresses can or will be used by the application issuing the query, it is obliged to translate all of them. When using SCTP in a multihomed network, the problem is exacerbated if multiple NAT-PTs translate multiple addresses. Also, it is not clear that SCTP will actually look up all the destination IP addresses via DNS, so that bindings may not be in place when packets arrive. http://www.ietf.org/rfc/rfc4980.txt 4980 Analysis of Multihoming in Network Mobility Support. C. Ng, T. Ernst, E. Paik, M. Bagnulo. October 2007. (Format: TXT=3D88572 = bytes) (Status: INFORMATIONAL) Analysis of Multihoming in Network Mobility Support This document is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. The possible deployment scenarios of multihomed mobile networks are described together with the associated issues when network mobility is supported by RFC 3963 (NEMO Basic Support). Recommendations are offered on how to address these issues. RFC 4980 Analysis of Multihoming in NEMO October 2007 3. Deployment Scenarios and Prerequisites . . . . . . . . . . . . 11 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11 3.2. Prerequisites . . . . . . . . . . . . . . . . . . . . . . 13 4. Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Fault Tolerance . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Failure Detection . . . . . . . . . . . . . . . . . . 15 4.1.2. Path Exploration . . . . . . . . . . . . . . . . . . . 16 4.1.3. Path Selection . . . . . . . . . . . . . . . . . . . . 17 4.1.4. Re-Homing . . . . . . . . . . . . . . . . . . . . . . 19 4.2. Ingress Filtering . . . . . . . . . . . . . . . . . . . . 19 4.3. HA Synchronization . . . . . . . . . . . . . . . . . . . . 21 4.4. MR Synchronization . . . . . . . . . . . . . . . . . . . . 22 4.5. Prefix Delegation . . . . . . . . . . . . . . . . . . . . 23 4.6. Multiple Bindings/Registrations . . . . . . . . . . . . . 23 4.7. Source Address Selection . . . . . . . . . . . . . . . . . 23 4.8. Loop Prevention in Nested Mobile Networks . . . . . . . . 24 4.9. Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24 4.10. Preference Settings . . . . . . . . . . . . . . . . . . . 25 5. Recommendations to the Working Group . . . . . . . . . . . . . 26 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 Appendix A. Alternative Classifications Approach . . . . . . . . 32 A.1. Ownership-Oriented Approach . . . . . . . . . . . . . . . 32 A.1.1. ISP Model . . . . . . . . . . . . . . . . . . . . . . 32 A.1.2. Subscriber/Provider Model . . . . . . . . . . . . . . 33 A.2. Problem-Oriented Approach . . . . . . . . . . . . . . . . 34 Appendix B. Nested Tunneling for Fault Tolerance . . . . . . . . 35 B.1. Detecting Presence of Alternate Routes . . . . . . . . . . 35 B.2. Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36 B.2.1. Using Alternate Egress Interface . . . . . . . . . . . 36 B.2.2. Using Alternate Mobile Router . . . . . . . . . . . . 36 B.3. To Avoid Tunneling Loop . . . . . . . . . . . . . . . . . 37 B.4. Points of Considerations . . . . . . . . . . . . . . . . . 37 RFC 4980 Analysis of Multihoming in NEMO October 2007 As specified in Section 5 of the NEMO Basic Support Requirements [1] (R.12), the NEMO WG must ensure that NEMO Basic Support does not prevent mobile networks to be multihomed, i.e., when there is more than one point of attachment between the mobile network and the Internet (see definitions in [3]). This arises either: RFC 4980 Analysis of Multihoming in NEMO October 2007 o to determine all the potential multihomed configurations for a NEMO, and then to identify which of these may be useful in a real- life scenario; o to capture issues that may prevent some multihomed configurations to be supported under the operation of NEMO Basic Support. It does not necessarily mean that the ones not supported will not work with NEMO Basic Support, as it may be up to the implementors to make it work (hopefully this memo will be helpful to these implementors); In order to reach these objectives, a taxonomy for classifying the possible multihomed configurations is described in Section 2. Deployment scenarios, their benefits, and requirements to meet these benefits are illustrated in Section 3. Following this, the related issues are studied in Section 4. The issues are then summarized in a matrix for each of the deployment scenario, and recommendations are made on which of the issues should be worked on and where in Section 5. This memo concludes with an evaluation of NEMO Basic Support for multihomed configurations. Alternative classifications are outlined in the Appendix. The readers should note that this document considers multihoming only from the point of view of an IPv6 environment. In order to understand this memo, the reader is expected to be familiar with the above cited documents, i.e., with the NEMO terminology as defined in [2] (Section 3) and [3], Motivations and Scenarios for Multihoming [6], Goals and Requirements of Network Mobility Support [1], and the NEMO Basic Support specification [4]. Goals and benefits of multihoming as discussed in [6], are applicable to fixed nodes, mobile nodes, fixed networks, and mobile networks. As there are several configurations in which mobile networks are multihomed, there is a need to classify them into a clearly defined taxonomy. This can be done in various ways. A Configuration- Oriented taxonomy is described in this section. Two other RFC 4980 Analysis of Multihoming in NEMO October 2007 Multihomed configurations can be classified depending on how many MRs are present, how many egress interfaces, Care-of Address (CoA), and Home Addresses (HoA) the MRs have, how many prefixes (MNPs) are available to the mobile network nodes, etc. We use three key parameters to differentiate the multihomed configurations. Using these parameters, each configuration is referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as follows: x=3D1 implies that a mobile network has only a single MR, presumably multihomed. As will be described in the sub-sections below, a total of 8 possible configurations can be identified. One thing the reader has to keep in mind is that in each of the following 8 cases, the MR may be multihomed if either (i) multiple prefixes are available (on the home link, or on the foreign link), or (ii) the MR is equipped with multiple interfaces. In such a case, the MR would have multiple (HoA,CoA) pairs. Issues pertaining to a multihomed MR are also addressed in [7]. In addition, the readers should also keep in mind that when "MNP(s) is/are available in the NEMO", the MNP(s) may either be explicitly announced by the MR via router advertisement, or made available through Dynamic Host Configuration Protocol (DHCP) [8]. RFC 4980 Analysis of Multihoming in NEMO October 2007 The (1,1,1) configuration has only one MR, it is associated with a single HA, and a single MNP is available in the NEMO. The MR and the AR are connected to the Internet via a single Access Router (AR). To fall into a multihomed configuration, at least one of the following conditions must hold: Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to. RFC 4980 Analysis of Multihoming in NEMO October 2007 The MR may itself be multihomed, as detailed in Section 2.1. In such a case, a bi-directional tunnel would be established between each (HoA,CoA) pair. Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address from each MNP available on the link. The NEMO is multihomed since it has multiple HAs, but in addition, the conditions detailed in Section 2.1 may also hold for the MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair. Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to. RFC 4980 Analysis of Multihoming in NEMO October 2007 The MR is multihomed since it has multiple HAs, but in addition, the conditions detailed in Section 2.1 may also hold. A bi-directional tunnel would then be established between each (HoA,CoA) pair. Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link. The NEMO is multihomed since it has multiple MRs, but in addition the conditions detailed in Section 2.1 may also hold for each MR. A bi- directional tunnel would then be established between each (HoA,CoA) pair. Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to. RFC 4980 Analysis of Multihoming in NEMO October 2007 The NEMO is multihomed since it has multiple MRs, but in addition, the conditions detailed in Section 2.1 may also hold for each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair. Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link. RFC 4980 Analysis of Multihoming in NEMO October 2007 The NEMO is multihomed since it has multiple MRs and HAs, but in addition, the conditions detailed in Section 2.1 may also hold for each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair. Regarding MNNs, they are (usually) not multihomed since they would configure a single global address from the single MNP available on the link they are attached to. The NEMO is multihomed since it has multiple MRs and HAs, but in addition, the conditions detailed in Section 2.1 may also hold for each MR. A bi-directional tunnel would then be established between each (HoA,CoA) pair. Regarding MNNs, they are multihomed because several MNPs are available on the link they are attached to. The MNNs would then configure a global address with each MNP available on the link. RFC 4980 Analysis of Multihoming in NEMO October 2007 The following generic goals and benefits of multihoming are discussed in [6]: x=3D1: Multihomed mobile networks with a single MR RFC 4980 Analysis of Multihoming in NEMO October 2007 x=3Dn: Multihomed mobile networks with multiple MRs y=3D1: Multihomed mobile networks with a single HA y=3Dn: Multihomed mobile networks with multiple HAs z=3D1: Multihomed mobile networks with a single MNP RFC 4980 Analysis of Multihoming in NEMO October 2007 z=3Dn: Multihomed mobile networks with multiple MNPs In this section, requirements are stated in order to comply with the expected benefits of multihoming as detailed in [6]. RFC 4980 Analysis of Multihoming in NEMO October 2007 4. Multihoming Issues One of the goals of multihoming is the provision of fault tolerance capabilities. In order to provide such features, a set of tasks need to be performed, including: failure detection, alternative available path exploration, path selection, and re-homing of established communications. These are also discussed in [9] by the Shim6 WG. In the following sub-sections, we look at these issues in the specific context of NEMO, rather than the general Shim6 perspective in [9]. In addition, in some scenarios, it may also be required to provide the mechanisms for coordination between different HAs (see Section 4.3) and also the coordination between different MRs (see Section 4.4). RFC 4980 Analysis of Multihoming in NEMO October 2007 Depending on the NEMO configuration considered, the failure protection domain greatly varies. In some configurations, the protection domain provided by NEMO multihoming is limited to the links between the MR(s) and the HA(s). In other configurations, the protection domain allows to recover from failures in other parts of the path, so an end-to-end failure detection mechanism is required. RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 A path-selection mechanism is required to select among the multiple available paths. Depending on the NEMO multihoming configuration involved, the differences between the paths may affect only the part between the HA and the MR, or they may affect the full end-to-end RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 The mechanisms for selecting among different end-to-end paths based on address selection are similar to the ones used in other multihoming scenarios, as those considered by Shim6 (e.g., [13]). After an outage has been detected and an available alternative path has been identified, a re-homing event takes place, diverting the existing communications from one path to the other. Similar to the previous items involved in this process, the re-homing procedure heavily varies depending on the NEMO multihoming configuration. RFC 4980 Analysis of Multihoming in NEMO October 2007 The ingress filtering compatibility issue is heavily dependent on the particular NEMO multihoming configuration: o (*,n,n) are the cases where the ingress filtering presents some difficulties. In the (1,n,n) case, the problem is simplified because all the traffic to and from the NEMO is routed through a single MR. Such configuration allows the MR to properly route packets respecting the constraints imposed by ingress filtering. In this case, the single MR may face ingress filtering problems that a multihomed mobile node may face, as documented in [7]. The more complex case is the (n,n,n) case. A simplified case occurs when all the prefixes are accepted by all the HAs, so that no problems occur with the ingress filtering. However, this cannot be always assumed, resulting in the problem described below. RFC 4980 Analysis of Multihoming in NEMO October 2007 The ingress filtering incompatibilities problems that appear in some NEMO multihoming configurations are similar to those considered in Shim6 (e.g., see [16]). RFC 4980 Analysis of Multihoming in NEMO October 2007 However, there is no known standardized protocol for this kind of router-to-router synchronization. Without such synchronization, it may not be possible for a (n,*,*) configuration to achieve various multihoming goals, such as fault tolerance. RFC 4980 Analysis of Multihoming in NEMO October 2007 Prefix delegation mechanisms [20][21][22] could be used to ensure all routers advertise the same MNP. Their applicability to a multihomed mobile network should be considered. RFC 4980 Analysis of Multihoming in NEMO October 2007 When a multihomed mobile network is nested within another mobile network, it can result in very complex topologies. For instance, a nested mobile network may be attached to two different root-MRs, thus the aggregated network no longer forms a simple tree structure. In such a situation, infinite loop within the mobile network may occur. This problem is specific to NEMO Basic Support. However, at the time of writing, more research is recommended to assess the probability of loops occurring in a multihomed mobile network. For related work, see [25] for a mechanism to avoid loops in nested NEMO. RFC 4980 Analysis of Multihoming in NEMO October 2007 When a mobile network is multihomed, the MNNs may be able to benefit from this configuration, such as to choose among the available paths based on cost, transmission delays, bandwidth, etc. However, in some cases, such a choice is not made available to the MNNs. Particularly: This problem is general in the sense that IPv6 nodes may wish to influence the routing decision done by the upstream routers. Such a mechanism is currently being explored by various WGs, such as the NSIS and IPFIX WGs. It is also possible that the Shim6 layer in the MNNs may possess such a capability. It is recommended for vendors or operators to investigate into the solutions developed by these WGs when providing multihoming capabilities to mobile networks. RFC 4980 Analysis of Multihoming in NEMO October 2007 Several issues that might impact the deployment of NEMO with multihoming capabilities were identified in Section 4. These are shown in the matrix below, for each of the eight multihoming configurations, together with indications from which WG(s) a solution to each issue is most likely to be found. Figure 10: Matrix of NEMO Multihoming Issues RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 Further research is recommended to assess the risk of having a loop in the nesting of multihomed mobile networks. This memo presented an analysis of multihoming in the context of network mobility under the operation of NEMO Basic Support (RFC 3963). The purpose was to investigate issues related to such a bi- directional tunneling mechanism where mobile networks are multihomed and multiple bi-directional tunnels are established between Home Agent and Mobile Router pairs. For doing so, mobile networks were classified into a taxonomy comprising eight possible multihomed configurations. Issues were explained one by one and then summarized into a table showing the multihomed configurations where they apply, suggesting the most relevant IETF working group where they could be solved. This analysis will be helpful to extend the existing standards to support multihoming and to implementors of NEMO Basic Support and multihoming-related mechanisms. This is an informational document where the multihoming configurations under the operation of NEMO Basic Support are analyzed. Security considerations of these multihoming configurations, should they be different from those that concern NEMO Basic Support, must be considered by forthcoming solutions. For instance, an attacker could try to use the multihomed device as a means to access another network that would not be normally reachable through the Internet. Even when forwarding to another network is turned off by configuration, an attacker could compromise a system to enable it. RFC 4980 Analysis of Multihoming in NEMO October 2007 The authors would like to thank people who have given valuable comments on various multihoming issues on the mailing list, and also those who have suggested directions in the 56th - 61st IETF Meetings. The initial evaluation of NEMO Basic Support on multihoming configurations is a contribution from Julien Charbon. [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, February 2006. [9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, December 2006. RFC 4980 Analysis of Multihoming in NEMO October 2007 [13] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", Work in Progress, November 2006. [15] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [16] Huitema, C. and M. Marcelo, "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, October 2006. RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 An alternative approach to classifying a multihomed mobile network was proposed by Erik Nordmark (Sun Microsystems) by breaking the classification of multihomed network based on ownership. This is more of a tree-like, top-down classification. Starting from the control and ownership of the HA(s) and MR(s), there are two different possibilities: either (i) the HA(s) and MR(s) are controlled by a single entity, or (ii) the HA(s) and MR(s) are controlled by separate entities. We called the first possibility the 'ISP Model', and the second the 'Subscriber/Provider Model'. RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 A third approach was proposed by Pascal Thubert (Cisco Systems). This focused on the problems of multihomed mobile networks rather than the configuration or ownership. With this approach, there is a set of 4 categories based on two orthogonal parameters: the number of HAs, and the number of MNPs advertised. Since the two parameters are orthogonal, the categories are not mutually exclusive. The four categories are: RFC 4980 Analysis of Multihoming in NEMO October 2007 In order to utilize the additional robustness provided by multihoming, MRs that employ bi-directional tunneling with their HAs should dynamically change their tunnel exit points depending on the link status. For instance, if an MR detects that one of its egress interface is down, it should detect if alternate routes to the global Internet exists. This alternate route may be provided by any other MRs connected to one of its ingress interfaces that has an independent route to the global Internet, or by another active egress interface the MR itself possesses. If such an alternate route exists, the MR should re-establish the bi-directional tunnel using this alternate route. To actively utilize the robustness provided by multihoming, an MR must first be capable of detecting alternate routes. This can be manually configured into the MR by the administrators if the configuration of the mobile network is relatively static. It is however highly desirable for MRs to be able to discover alternate routes automatically for greater flexibility. RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 RFC 4980 Analysis of Multihoming in NEMO October 2007 http://www.ietf.org/rfc/rfc4982.txt 4982 Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs). M. Bagnulo, J. Arkko. July 2007. = (Format: TXT=3D20961 bytes) (Updates RFC3972) (Status: PROPOSED STANDARD) o The application of CGAs to protect the shim6 protocol [7]. In this case, CGAs are used as identifiers for the established communications. CGA features are used to prove that the owner of the identifier is the one that is providing the alternative addresses that can be used to reach the initial identifier. This is achieved by signing the list of alternative addresses available in the multihomed host with the private key of the CGA. [7] Nordmark, E. and M. Bagnulo, "Multihoming L3 Shim Approach", Work in Progress, July 2005. http://www.ietf.org/rfc/rfc4984.txt 4984 Report from the IAB Workshop on Routing and Addressing. D. Meyer, Ed., L. Zhang, Ed., K. Fall, Ed.. September 2007. (Format: = TXT=3D96153 bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Key Findings from the Workshop . . . . . . . . . . . . . . . . 4 2.1. Problem #1: The Scalability of the Routing System . . . . 4 2.1.1. Implications of DFZ RIB Growth . . . . . . . . . . . . 5 2.1.2. Implications of DFZ FIB Growth . . . . . . . . . . . . 6 2.2. Problem #2: The Overloading of IP Address Semantics . . . 6 2.3. Other Concerns . . . . . . . . . . . . . . . . . . . . . . 7 2.4. How Urgent Are These Problems? . . . . . . . . . . . . . . 8 3. Current Stresses on the Routing and Addressing System . . . . 8 3.1. Major Factors Driving Routing Table Growth . . . . . . . . 8 3.1.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . 9 3.1.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. Traffic Engineering . . . . . . . . . . . . . . . . . 10 3.2. IPv6 and Its Potential Impact on Routing Table Size . . . 11 4. Implications of Moore's Law on the Scaling Problem . . . . . . 11 4.1. Moore's Law . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. DRAM . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. Off-chip SRAM . . . . . . . . . . . . . . . . . . . . 13 4.2. Forwarding Engines . . . . . . . . . . . . . . . . . . . . 13 4.3. Chip Costs . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Heat and Power . . . . . . . . . . . . . . . . . . . . . . 14 4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. What Is on the Horizon . . . . . . . . . . . . . . . . . . . . 15 5.1. Continual Growth . . . . . . . . . . . . . . . . . . . . . 15 5.2. Large Numbers of Mobile Networks . . . . . . . . . . . . . 16 5.3. Orders of Magnitude Increase in Mobile Edge Devices . . . 16 6. What Approaches Have Been Investigated . . . . . . . . . . . . 17 6.1. Lessons from MULTI6 . . . . . . . . . . . . . . . . . . . 17 6.2. SHIM6: Pros and Cons . . . . . . . . . . . . . . . . . . . 18 6.3. GSE/Indirection Solutions: Costs and Benefits . . . . . . 19 6.4. Future for Indirection . . . . . . . . . . . . . . . . . . 20 7. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Problem #1: Routing Scalability . . . . . . . . . . . . . 21 7.2. Problem #2: The Overloading of IP Address Semantics . . . 22 7.2.1. Definition of Locator and Identifier . . . . . . . . . 22 7.2.2. Consequence of Locator and Identifier Overloading . . 23 7.2.3. Traffic Engineering and IP Address Semantics Overload . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Additional Issues . . . . . . . . . . . . . . . . . . . . 24 7.3.1. Routing Convergence . . . . . . . . . . . . . . . . . 24 7.3.2. Misaligned Costs and Benefits . . . . . . . . . . . . 25 7.3.3. Other Concerns . . . . . . . . . . . . . . . . . . . . 25 7.4. Problem Recognition . . . . . . . . . . . . . . . . . . . 26 8. Criteria for Solution Development . . . . . . . . . . . . . . 26 8.1. Criteria on Scalability . . . . . . . . . . . . . . . . . 26 8.2. Criteria on Incentives and Economics . . . . . . . . . . . 27 The clear, highest-priority takeaway from the workshop is the need to devise a scalable routing and addressing system, one that is scalable in the face of multihoming, and that facilitates a wide spectrum of traffic engineering (TE) requirements. Several scalability problems of the current routing and addressing systems were discussed, most related to the size of the DFZ routing table (frequently referred to as the Routing Information Base, or RIB) and its implications. Those implications included (but were not limited to) the sizes of the DFZ RIB and FIB (the Forwarding Information Base), the cost of recomputing the FIB, concerns about the BGP convergence times in the presence of growing RIB and FIB sizes, and the costs and power (and hence heat dissipation) properties of the hardware needed to route traffic in the core of the Internet. o Multihoming, Finally, it was noted by the workshop participants that the UPDATE churn situation may be exacerbated by the current Regional Internet Registry (RIR) policy in which end sites are allocated Provider- Independent (PI) addresses. These addresses are not topologically aggregatable, and as such, bring the churn problem described above into the core routing system. Of course, as noted by several participants, the RIRs have no real choice in this matter, as many enterprises demand PI addresses that allow them to multihome without the "provider lock" that Provider-Allocated (PA) [PIPA] address space creates. Some enterprises also find the renumbering cost associated with PA address assignments unacceptable. The primary concern voiced by the workshop participants regarding the state of the current Internet routing system was the rapid growth of the DFZ RIB. The number of entries in 2005 ranged from about 150,000 entries to 175,000 entries [BGP2005]; this number has reached 200,000 as of October 2006 [CIDRRPT], and is projected to increase to 370,000 or more within 5 years [Fuller]. Some workshop participants projected that the DFZ could reach 2 million entries within 15 years, and there might be as many as 10 million multihomed sites by 2050. 3.1.2. Multihoming Multihoming refers generically to the case in which a site is served by more than one ISP [RFC4116]. There are several reasons for the observed increase in multihoming, including the increased reliance on the Internet for mission- and business-critical applications and the general decrease in cost to obtain Internet connectivity. Multihoming provides backup routing -- Internet connection redundancy; in some circumstances, multihoming is mandatory due to contract or law. Multihoming can be accomplished using either PI or PA address space, and multihomed sites generally have their own AS numbers (although some do not; this generally occurs when such customers are statically routed). A multihomed site using PI address space has its prefixes present in the forwarding and routing tables of each of its providers. For PA space, each prefix allocated from one provider's address allocation will be aggregatable for that provider but not the others. If the addresses are allocated from a 'primary' ISP (i.e., one that the site uses for routing unless a failure occurs), then the additional routing table entries only appear during path failures to that primary ISP. A problem with multihoming arises when a customer's PA IP prefixes are advertised by AS(es) other than their 'primary' ISP's. Because of the longest-matching prefix forwarding rule, in this case, the customer's traffic will be directed through the non- primary AS(s). In response, the primary ISP is forced to de- aggregate the customer's prefix in order to keep the customer's traffic flowing through it instead of the non-primary AS(s). 2. The solution to multihoming being developed by the SHIM6 Working Group, and its pros and cons, 4. Map-and-Encap [RFC1955], a general indirection-based solution to scalable multihoming support. The MULTI6 working group was chartered to explore the solution space for scalable support of IPv6 multihoming. The numerous proposals collected by MULTI6 working group generally fell into one of two major categories: resolving the above-mentioned conflict by using provider-independent address assignments, or by assigning multiple address prefixes to multihomed sites, one for each of its providers, so that all the addresses can be topologically aggregatable. the ability to control the traffic flow of the entire site. Conversely, handling multiple addresses by individual hosts offers each host the flexibility to choose different policies for selecting a provider; it also implies changes to all the hosts of a multihomed site. The SHIM6 working group took the second approach from the MULTI6 working group's investigation, i.e., supporting multihoming through the use of multiple addresses. SHIM6 adopted a host-based approach, where the host IP stack includes a "shim" that presents a stable "upper layer identifier" (ULID) to the upper layer protocols, but may rewrite the IP packets sent and received so that a currently working IP address is used in the transmitted packets. When needed, a SHIM6 header is also included in the packet itself, to signal to the remote stack. SHIM6 is able to isolate upper layer protocols from multiple IP layer addresses. This enables a multihomed site to use provider-allocated prefixes, one from each of its multiple providers, to facilitate provider-based prefix aggregation. However, this gain comes with several significant costs. First, SHIM6 requires modifications to all host stack implementations to support the shim processing. Second, the shim layer must maintain the mapping between the identifier and the multiple locators returned from IPv6 AAAA name resolution, and must take the responsibility to try multiple locators if failures ever occur during the end-to-end communication. At this time, the host has little information to determine the order of locators it should use in reaching a multihomed destination, however, there is ongoing effort in addressing this issue. Yet another major issue with the SHIM6 solution is the need for renumbering when a site changes providers. Although a multihomed site is assigned multiple address blocks, none of them can be treated as a persistent identifier for the site. When the site changes one of its providers, it must purge the address block of that provider from the entire site. The current practice of using the IP address as both an identifier and a locator has been strengthened by the use of IP addresses in access control lists present in various types of policy-enforcement devices (e.g., firewalls). If SHIM6's ULIDs are to be used for policy enforcement, a change of providers may necessitate the re-configuration of many such devices. The use of indirection for scalable multihoming was discussed at the workshop, including the GSE [GSE] and indirection approaches, such as Map-and-Encap [RFC1955], in general. The GSE proposal changes the IPv6 address structure to bear the semantics of both an identifier and a locator. The first n bytes of the 16-byte IPv6 address are called the Routing Goop (RG), and are used by the routing system exclusively as a locator. The last 8 bytes of the IPv6 address specify an interface on an end-system. The middle (16 - n - 8) bytes are used to identify site local topology. The border routers of a site re-write the source RG of each outgoing packet to make the source address part of the source provider's address aggregation; they also re-write the destination RG of each incoming packet to hide the site's RG from all the internal routers and hosts. Although GSE All identifier/locator split proposals require a mapping service that can return a set of locators corresponding to a given identifier. In addition, these proposals must also address the problem of detecting locator failures and redirecting data flows to remaining locators for a multihomed site. The Map-and-Encap proposal did not address these issues. GSE proposed to use DNS for providing the mapping service, but it did not offer an effective means for locator failure recovery. GSE also requires host stack modifications, as the upper layers and applications are only allowed to use the lower 8-bytes, rather than the entire, IPv6 address. As the saying goes, "There is no problem in computer science that cannot be solved by an extra level of indirection". The GSE proposal can be considered a specific instantiation of a class of indirection- based solutions to scalable multihoming. Map-and-Encap [RFC1955] represents a more general form of this indirection solution, which uses tunneling, instead of locator rewriting, to cross the DFZ and support provider-based prefix aggregation. This class of solutions avoids the provider and customer conflicts regarding PA and PI prefixes by putting each in a separate name space, so that ISPs can use topologically aggregatable addresses while customers can have their globally unique and provider-independent identifiers. Thus, it supports scalable multihoming, and requires no changes to the end systems when the encapsulation is performed by the border routers of a site. It also requires no changes to the current practice of both applications as well as backbone operations. As we have reported in Section 3, multihoming, along with traffic engineering, appear to be the major factors driving the growth of the DFZ RIB. Below, we elaborate their impact on the DFZ RIB. Consider, for example, a campus network C that received prefix x.y.z/24 from provider P1. When C multihomes with a second provider P2, both P1 and P2 must announce x.y.z/24 so that C can be reached through both providers. In this example, the prefix x.y.z/24 serves both as an identifier for C, as well as a (non-aggregatable) locator for C's two attachment points to the transit system. As far as the DFZ RIB is concerned, the above example shows that customer multihoming blurs the distinction between PA and PI prefixes. Although C received a PA prefix x.y.z/24 from P1, C's multihoming forced this prefix to be announced globally (equivalent to a PI prefix), and forced the prefix's original owner, provider P1, to de-aggregate. As a result, today's multihoming practice leads to a growth of the routing table size in proportion to the number of multihomed customers. The only practical way to scale a routing system today is topological aggregation, which gets destroyed by customer multihoming. Although multihoming may blur the PA/PI distinction, there exists a big difference between PA and PI prefixes when a customer changes its provider(s). If the customer has used a PA prefix from a former provider P1, the prefix is supposed to be returned to P1 upon completion of the change. The customer is supposed to get a new prefix from its new provider, i.e., renumbering its network. It is necessary for providers to reclaim their PA prefixes from former customers in order to keep the topological aggregatiblity of their prefixes. On the other hand, renumbering is considered very painful, if not impossible, by many Internet users, especially large enterprise customers. It is not uncommon for IP addresses in such enterprises to penetrate deeply into various parts of the networking infrastructure, ranging from applications to network management (e.g., policy databases, firewall configurations, etc.). This shows how fragile the system becomes due to the overloading of IP addresses as both locators and identifiers; significant enterprise operations could be disrupted due to the otherwise simple operation of switching IP address prefix assignment. Today's rapid growth of the DFZ RIB is driven by a few major factors, including multihoming and traffic engineering, in addition to the organic growth of the Internet's user base. There is a powerful incentive to deploy each of the above features, as they bring direct benefits to the parties who make use of them. However, the beneficiaries may not bear the direct costs of the resulting routing table size increase, and there is no measurable or enforceable constraint to limit such increase. For example, suppose that a service provider has two bandwidth- constrained transoceanic links and wants to split its prefix announcements in order to fully load each link. The origin AS benefits from performing the de-aggregation. However, if the de- aggregated announcements propagate globally, the cost is born by all other ASs. That is, the costs of this type of TE practice are not contained to the beneficiaries. Multihoming provides a similar example (in this case, the multihomed site achieves a benefit, but the global Internet incurs the cost of carrying the additional prefix(es)). Clearly, any proposed solution must solve the problem at hand, and our number one problem concerns the scalability of the Internet's routing and addressing system(s) as outlined in previous sections. Under the assumption of continued growth of the Internet user population, continued increases of multihoming and RFC 2547 VPN [RFC2547] deployment, the solution must enable the routing system to scale gracefully, as measured by the number of presented in Section 6, where we examined the gains and costs of a few different approaches to scalable multihoming support (SHIM6, GSE, and a general tunneling approach). A major task in the solution development is to understand who may have to give up what, and whether that makes a worthy tradeoff. [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. [SHIM6] "Site Multihoming by IPv6 Intermediation (shim6)", http://www.ietf.org/html.charters/shim6-charter.html. [dGSE] Zhang, L., "An Overview of Multihoming and Open Issues in GSE", IETF Journal, http://www.isoc.org/tools/blogs/ ietfjournal/?p=3D98#more-98, 2006. [Fuller] Fuller, V., "Scaling issues with ipv6 routing+ multihoming", http://www.iab.org/about/workshops/ routingandaddressing/vaf-iab-raws.pdf, 2006. 0900-1200: Morning session Moderator: Elwyn Davies Strawman topics for the morning session: - Scalability - Multihoming support - Traffic Engineering - Routing Table Size: Rate of growth, Dynamics (this is not limited to DFZ, include iBGP) - Causes of the growth - Pains from the growth (perhaps "Impact on routers" can come here?) - How big a problem is BGP slow convergence? http://www.ietf.org/rfc/rfc4987.txt 4987 TCP SYN Flooding Attacks and Common Mitigations. W. Eddy. August 2007. (Format: TXT=3D48753 bytes) (Status: INFORMATIONAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5000.txt 5000 Internet Official Protocol Standards. RFC Editor. May 2008. (Format: TXT=3D222566 bytes) (Obsoletes RFC3700) (Also STD0001) (Status: INFORMATIONAL) -------- Session Description Protocol (SDP) Security 4568* Descriptions for Media Streams -------- Key Management Extensions for Session Description 4567* Protocol (SDP) and Real Time Streaming Protocol (RTSP) SDP SDP: Session Description Protocol 4566* -------- The Key ID Information Type for the General 4563* Extension Payload in Multimedia Internet KEYing (MIKEY) -------- Definition of a Record Route Object (RRO) Node-Id 4561* Sub-Object -------- Definitions of Managed Objects for Remote Ping, 4560* Traceroute, and Lookup Operations -------- Node-ID Based Resource Reservation Protocol (RSVP) 4558* Hello: A Clarification Statement -------- Online Certificate Status Protocol (OCSP) Support 4557* for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) -------- Public Key Cryptography for Initial Authentication 4556* in Kerberos (PKINIT) -------- IKEv2 Mobility and Multihoming Protocol (MOBIKE) 4555* SAToP Structure-Agnostic Time Division Multiplexing (TDM) 4553* over Packet (SAToP) -------- Authentication/Confidentiality for OSPFv3 4552* -------- IMAP Extension for Conditional STORE Operation or 4551* Quick Flag Changes Resynchronization -------- Internet Email to Support Diverse Service 4550* Environments (Lemonade) Profile -------- Internet Code Point (ICP) Assignments for NSAP 4548* Addresses -------- Event Notification Management Information Base for 4547* Data over Cable Service Interface Specifications (DOCSIS)-Compliant Cable Modems and Cable Modem Termination Systems -------- Radio Frequency (RF) Interface Management 4546* Information Base for Data over Cable Service Interface Specifications (DOCSIS) 2.0 Compliant RF Interfaces -------- Definitions of Managed Objects for IP Storage User 4545* Identity Authorization -------- Definitions of Managed Objects for Internet Small 4544* Computer System Interface (iSCSI) -------- The Use of Galois Message Authentication Code (GMAC) 4543* in IPsec ESP and AH -------- Request Authorization through Dialog Identification 4538* in the Session Initiation Protocol (SIP) -------- Kerberos Cryptosystem Negotiation Extension 4537* -------- Session Initiation Protocol (SIP) Basic Call Flow 3665 75 Examples -------- Session Initiation Protocol (SIP) Public Switched 3666 76 Telephone Network (PSTN) Call Flows -------- IETF ISOC Board of Trustee Appointment Procedures 3677 77 -------- IETF Rights in Contributions 3978* 78 -------- RFC 3978 Update to Recognize the IETF Trust 4748* 78 -------- Intellectual Property Rights in IETF Technology 3979* 79 -------- Clarification of the Third Party Disclosure 4879* 79 Procedure in RFC 3979 -------- Delegation of E.F.F.3.IP6.ARPA 3681 80 -------- The IETF XML Registry 3688 81 -------- Assigning Experimental and Testing Numbers 3692 82 Considered Useful -------- A Practice for Revoking Posting Rights to IETF 3683 83 Mailing Lists -------- Ingress Filtering for Multihomed Networks 3704 84 -------- Best Current Practices for Third Party Call 3725 85 Control (3pcc) in the Session Initiation Protocol (SIP) -------- Determining Strengths For Public Keys Used For 3766 86 Exchanging Symmetric Keys -------- Use of Interior Gateway Protocol (IGP) Metric as a 3785 87 second MPLS Traffic Engineering (TE) Metric -------- IANA Considerations for the Point-to-Point 3818 88 Protocol (PPP) -------- Advice for Internet Subnetwork Designers 3819 89 -------- Registration Procedures for Message Header Fields 3864* 90 -------- DNS IPv6 Transport Operational Guidelines 3901* 91 -------- The IESG and RFC Editor Documents: Procedures 3932* 92 -------- A Model for IETF Process Experiments 3933* 93 -------- Updates to RFC 2418 Regarding the Management of 3934* 94 IETF Mailing Lists -------- A Mission Statement for the IETF 3935* 95 -------- Procedures for Modifying the Resource reSerVation 3936* 96 Protocol (RSVP) -------- Clarifying when Standards Track Documents may 3967* 97 Refer Normatively to Documents at a Lower Level -------- Handling Normative References to Standards-Track 4897* 97 Documents -------- The Internet Assigned Number Authority (IANA) 3968* 98 Header Field Parameter Registry for the Session Initiation Protocol (SIP) -------- The Internet Assigned Number Authority (IANA) 3969* 99 Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP -------- Early IANA Allocation of Standards Track Code 4020* 100 Points -------- Early IANA Allocation of Standards Track Code 100 4020* Points -------- Intellectual Property Rights in IETF Technology 79 3979* -------- IETF Rights in Contributions 78 3978* -------- The Internet Assigned Number Authority (IANA) 99 3969* Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP) -------- The Internet Assigned Number Authority (IANA) 98 3968* Header Field Parameter Registry for the Session Initiation Protocol (SIP) -------- Clarifying when Standards Track Documents may 97 3967* Refer Normatively to Documents at a Lower Level -------- Procedures for Modifying the Resource 96 3936* reSerVation Protocol (RSVP) -------- A Mission Statement for the IETF 95 3935* -------- Updates to RFC 2418 Regarding the Management of 94 3934* IETF Mailing Lists -------- A Model for IETF Process Experiments 93 3933* -------- The IESG and RFC Editor Documents: Procedures 92 3932* -------- DNS IPv6 Transport Operational Guidelines 91 3901* -------- Registration Procedures for Message Header Fields 90 3864* -------- Advice for Internet Subnetwork Designers 89 3819 -------- IANA Considerations for the Point-to-Point 88 3818 Protocol (PPP) -------- Use of Interior Gateway Protocol (IGP) Metric as 87 3785 a second MPLS Traffic Engineering (TE) Metric -------- IAB and IESG Selection, Confirmation, and Recall 10 3777 Process: Operation of the Nominating and Recall Committees -------- Determining Strengths For Public Keys Used For 86 3766 Exchanging Symmetric Keys -------- Best Current Practices for Third Party Call 85 3725 Control (3pcc) in the Session Initiation Protocol (SIP) -------- Ingress Filtering for Multihomed Networks 84 3704 -------- Assigning Experimental and Testing Numbers 82 3692 Considered Useful -------- The IETF XML Registry 81 3688 -------- A Practice for Revoking Posting Rights to IETF 83 3683 Mailing Lists -------- Delegation of E.F.F.3.IP6.ARPA 80 3681 -------- IETF ISOC Board of Trustee Appointment Procedures 77 3677 -------- Session Initiation Protocol (SIP) Public 76 3666 Switched Telephone Network (PSTN) Call Flows -------- Session Initiation Protocol (SIP) Basic Call 75 3665 Flow Examples http://www.ietf.org/rfc/rfc5043.txt 5043 Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation. C. Bestler, Ed., R. Stewart, Ed.. October 2007. (Format: TXT=3D38740 bytes) (Status: PROPOSED STANDARD) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Adaptation Layer Indicator . . . . . . . . . . . . . . . . 5 5.2. Payload Data Chunks . . . . . . . . . . . . . . . . . . . 6 5.2.1. DDP Source Sequence Number (DDP-SSN) . . . . . . . . . 6 5.2.2. DDP Segment Chunk . . . . . . . . . . . . . . . . . . 7 5.2.3. DDP Stream Session Control . . . . . . . . . . . . . . 7 6. DDP Stream Sessions . . . . . . . . . . . . . . . . . . . . . 8 6.1. Sequencing . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Legal Sequence: Active/Passive Session Accepted . . . . . 9 6.3. Legal Sequence: Active/Passive Session Rejected . . . . . 9 6.4. Legal Sequence: Active/Passive Session Non-ULP Rejected . 10 6.5. ULP-Specific Sequencing . . . . . . . . . . . . . . . . . 10 6.6. Other Sequencing Rules . . . . . . . . . . . . . . . . . . 10 7. SCTP Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Adaptation Layer Indication Restriction . . . . . . . . . 11 7.2. Multihoming Implications . . . . . . . . . . . . . . . . . 11 8. Number of Streams . . . . . . . . . . . . . . . . . . . . . . 12 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Sequenced Unordered Operation . . . . . . . . . . . . . . . . 13 11. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Association Initialization . . . . . . . . . . . . . . . . 13 11.2. Chunk Bundling . . . . . . . . . . . . . . . . . . . . . . 14 11.3. Association Termination . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 16.1. Normative References . . . . . . . . . . . . . . . . . . . 16 16.2. Informative References . . . . . . . . . . . . . . . . . . 16 SCTP endpoint - The logical sender/receiver of SCTP packets. On a multihomed host, an SCTP endpoint is represented to its peers as a combination of an SCTP port number and a set of eligible destination transport addresses to which SCTP packets can be sent. 7.2. Multihoming Implications Even when multihoming is supported, ULPs are cautioned that they SHOULD NOT use ULP control of the source address in an attempt to load-balance a stream across multiple paths. A receiving DDP/SCTP implementation that chooses to support multihoming SHOULD optimize its design on the assumption that multihoming will be used for network fault tolerance, and not to load-balance between paths. This is consistent with recommended SCTP practices. http://www.ietf.org/rfc/rfc5058.txt 5058 Explicit Multicast (Xcast) Concepts and Options. R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms. November 2007. (Format: TXT=3D80072 bytes) (Status: EXPERIMENTAL) Another possibility is to deploy a few of these Xcast-aware routers at various points in the network and to configure each of these with the special 32-bit address. This provides redundancy, eliminating the single point of failure, and reduces the distance an Xcast packet needs to travel to reach an Xcast-aware router, reducing network latencies. In this case, the Xcast-aware routers appear to be a single server that is "multihomed" (i.e., connected to the network at more than one place) and the non-Xcast-aware routers will, via ordinary unicast routing, deliver packets that are addressed to this "multihomed virtual server" via the shortest available path. http://www.ietf.org/rfc/rfc5062.txt 5062 Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures. R. Stewart, M. Tuexen, G. Camarillo. September 2007. (Format: TXT=3D29704 bytes) (Status: INFORMATIONAL) [EFFECTS] Aura, T., Nikander, P., and G. Camarillo, "Effects of Mobility and Multihoming on Transport-Layer Security", Security and Privacy 2004, IEEE Symposium , URL http:// research.microsoft.com/users/tuomaura/Publications/ aura-nikander-camarillo-ssp04.pdf, May 2004. http://www.ietf.org/rfc/rfc5082.txt 5082 The Generalized TTL Security Mechanism (GTSM). V. Gill, J. Heasley, D. Meyer, P. Savola, Ed., C. Pignataro. October 2007. (Format: TXT=3D36579 bytes) (Obsoletes RFC3682) (Status: PROPOSED STANDARD) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5095.txt 5095 Deprecation of Type 0 Routing Headers in IPv6. J. Abley, P. Savola, G. Neville-Neil. December 2007. (Format: TXT=3D13423 bytes) (Updates RFC2460, RFC4294) (Status: PROPOSED STANDARD) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5135.txt 5135 IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT). D. Wing, T. Eckert. February 2008. (Format: TXT=3D36528 bytes) (Also BCP0135) (Status: = BEST CURRENT PRACTICE) a: NATs that support the above requirement MUST also provide a configuration option to disable this feature. Otherwise, a multihomed network would cause duplicate instances of the multicast data traffic on the public network. a: NATs that support the above requirement MUST also provide a configuration option to disable this feature. Otherwise, a multihomed network would cause duplicate instances of the multicast data traffic on the public network. http://www.ietf.org/rfc/rfc5164.txt 5164 Mobility Services Transport: Problem Statement. T. Melia, Ed.. March 2008. (Format: TXT=3D33726 bytes) (Status: INFORMATIONAL) Multihoming: For some Information Services exchanged with the MN, there is a possibility that the request and response messages could be carried over two different links. For example, a handover command request is on the current link while the response could be delivered on the new link. It is expected that the transport protocol is capable of receiving information via multiple links. It is also expected that the MSTP user combines information belonging to the same session/transaction. When mobility is applied, the underlying IP mobility mechanism should provide session continuity when required. [8] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc5177.txt 5177 Network Mobility (NEMO) Extensions for Mobile IPv4. K. Leung, G. Dommety, V. Narayanan, A. Petrescu. April 2008. (Format: TXT=3D56094 bytes) (Status: PROPOSED STANDARD) Multihoming for Mobile Routers is outside the scope of this document. http://www.ietf.org/rfc/rfc5201.txt 5201 Host Identity Protocol. R. Moskowitz, P. Nikander, P. Jokela, Ed., T. Henderson. April 2008. (Format: TXT=3D240492 bytes) = (Status: EXPERIMENTAL) o "End-Host Mobility and Multihoming with the Host Identity Protocol" [RFC5206]: how to support mobility and multihoming in HIP on the HIP I1, R1, I2, and R2 packets only. Other states may be introduced by mechanisms in other specifications (such as mobility and multihoming). The system first determines whether there are any outstanding UPDATE messages that may conflict with the new UPDATE message under consideration. When multiple UPDATEs are outstanding (not yet acknowledged), the sender must assume that such UPDATEs may be processed in an arbitrary order. Therefore, any new UPDATEs that depend on a previous outstanding UPDATE being successfully received and acknowledged MUST be postponed until reception of the necessary ACK(s) occurs. One way to prevent any conflicts is to only allow one outstanding UPDATE at a time. However, allowing multiple UPDATEs may improve the performance of mobility and multihoming protocols. [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. [SHIM6-PROTO] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", Work in Progress, February 2008. http://www.ietf.org/rfc/rfc5202.txt 5202 Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP). P. Jokela, R. Moskowitz, P. Nikander. April 2008. (Format: TXT=3D68195 bytes) (Status: EXPERIMENTAL) During the initial ESP SA setup, the hosts send the SPI value that they want the peer to use when sending ESP data to them. The value is set in the NEW SPI field of the ESP_INFO parameter. In the initial setup, an old value for the SPI does not exist, thus the OLD SPI value field is set to zero. The OLD SPI field value may also be zero when additional SAs are set up between HIP hosts, e.g., in case of multihomed HIP hosts [RFC5206]. However, such use is beyond the scope of this specification. [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. http://www.ietf.org/rfc/rfc5204.txt 5204 Host Identity Protocol (HIP) Rendezvous Extension. J. Laganier, L. Eggert. April 2008. (Format: TXT=3D30233 bytes) (Status: EXPERIMENTAL) The End-Host Mobility and Multihoming with the Host Identity Protocol specification [RFC5206] allows a HIP node to notify its peers about changes in its set of IP addresses. This specification presumes initial reachability of the two nodes with respect to each other. [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. http://www.ietf.org/rfc/rfc5205.txt 5205 Host Identity Protocol (HIP) Domain Name System (DNS) Extensions. P. Nikander, J. Laganier. April 2008. (Format: TXT=3D34799 bytes) (Status: EXPERIMENTAL) [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. http://www.ietf.org/rfc/rfc5206.txt 5206 End-Host Mobility and Multihoming with the Host Identity Protocol. P. Nikander, T. Henderson, Ed., C. Vogt, J. Arkko. April 2008. (Format: TXT=3D99430 bytes) (Status: EXPERIMENTAL) End-Host Mobility and Multihoming with the Host Identity Protocol This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 3. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Operating Environment . . . . . . . . . . . . . . . . . . 5 3.1.1. Locator . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Mobility Overview . . . . . . . . . . . . . . . . . . 8 3.1.3. Multihoming Overview . . . . . . . . . . . . . . . . . 8 3.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Mobility with a Single SA Pair (No Rekeying) . . . . . 9 3.2.2. Mobility with a Single SA Pair (Mobile-Initiated Rekey) . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Host Multihoming . . . . . . . . . . . . . . . . . . . 11 3.2.4. Site Multihoming . . . . . . . . . . . . . . . . . . . 13 3.2.5. Dual host multihoming . . . . . . . . . . . . . . . . 14 3.2.6. Combined Mobility and Multihoming . . . . . . . . . . 14 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 One consequence of such a decoupling is that new solutions to network-layer mobility and host multihoming are possible. There are potentially many variations of mobility and multihoming possible. The scope of this document encompasses messaging and elements of procedure for basic network-level mobility and simple multihoming, leaving more complicated scenarios and other variations for further study. More specifically: However, while the same LOCATOR parameter is intended to support host multihoming (parallel support of a number of addresses), and experimentation is encouraged, detailed elements of procedure for host multihoming are left for further study. There are a number of situations where the simple end-to-end readdressing functionality is not sufficient. These include the initial reachability of a mobile host, location privacy, simultaneous mobility of both hosts, and some modes of NAT traversal. In these situations, there is a need for some helper functionality in the network, such as a HIP rendezvous server [RFC5204]. Such functionality is out of the scope of this document. We also do not consider localized mobility management extensions (i.e., mobility management techniques that do not involve directly signaling the correspondent node); this document is concerned with end-to-end mobility. Finally, making underlying IP mobility transparent to the transport layer has implications on the proper response of transport congestion control, path MTU selection, and Quality of Service (QoS). Transport-layer mobility triggers, and the proper transport response to a HIP mobility or multihoming address change, are outside the scope of this document. RFC 5206 HIP Mobility and Multihoming April 2008 Credit Based Authorization. A host must verify a mobile or multihomed peer's reachability at a new locator. Credit-Based Authorization authorizes the peer to receive a certain amount of data at the new locator before the result of such verification is known. RFC 5206 HIP Mobility and Multihoming April 2008 The general deployment model for HIP is shown above, assuming operation in an end-to-end fashion. This document specifies extensions to the HIP protocol to enable end-host mobility and basic multihoming. In summary, these extensions to the HIP base protocol enable the signaling of new addressing information to the peer in HIP messages. The messages are authenticated via a signature or keyed hash message authentication code (HMAC) based on its Host Identity. This document specifies the format of this new addressing (LOCATOR) parameter, the procedures for sending and processing this parameter to enable basic host mobility, and procedures for a concurrent address verification mechanism. RFC 5206 HIP Mobility and Multihoming April 2008 Figure 2: Architecture for HIP Mobility and Multihoming (MH) Consider first the case in which there is no mobility or multihoming, as specified in the base protocol specification [RFC5201]. The HIP base exchange establishes the HITs in use between the hosts, the SPIs to use for ESP, and the IP addresses (used in both the HIP signaling packets and ESP data packets). Note that there can only be one such set of bindings in the outbound direction for any given packet, and the only fields used for the binding at the HIP layer are the fields exposed by ESP (the SPI and HITs). For the inbound direction, the SPI is all that is required to find the right host context. ESP rekeying events change the mapping between the HIT pair and SPI, but do not change the IP addresses. RFC 5206 HIP Mobility and Multihoming April 2008 Finally, consider the case when a host is multihomed (has more than one globally routable address) and has multiple addresses available at the HIP layer as alternative locators for fault tolerance. Examples include the use of (possibly multiple) IPv4 and IPv6 addresses on the same interface, or the use of multiple interfaces attached to different service providers. Such host multihoming generally necessitates that a separate ESP SA is maintained for each interface in order to prevent packets that arrive over different paths from falling outside of the ESP anti-replay window [RFC4303]. Multihoming thus makes it possible that the bindings shown on the right side of Figure 2 are one to many (in the outbound direction, one HIT pair to multiple SPIs, and possibly then to multiple IP addresses). However, only one SPI and address pair can be used for any given packet, so the job of the "MH" block depicted above is to dynamically manipulate these bindings. Beyond locally managing such multiple bindings, the peer-to-peer HIP signaling protocol needs to be flexible enough to define the desired mappings between HITs, SPIs, and addresses, and needs to ensure that UPDATE messages are sent along the right network paths so that any HIP-aware middleboxes can observe the SPIs. This document does not specify the "MH" block, nor does it specify detailed elements of procedure for how to handle various multihoming (perhaps combined with mobility) scenarios. The "MH" block may apply to more general problems outside of HIP. However, this document does describe a basic multihoming case (one host adds one address to its initial address and notifies the peer) and leave more complicated scenarios for experimentation and future documents. This document defines a generalization of an address called a "locator". A locator specifies a point-of-attachment to the network but may also include additional end-to-end tunneling or per-host demultiplexing context that affects how packets are handled below the logical HIP sublayer of the stack. This generalization is useful because IP addresses alone may not be sufficient to describe how packets should be handled below HIP. For example, in a host multihoming context, certain IP addresses may need to be associated with certain ESP SPIs to avoid violating the ESP anti-replay window. Addresses may also be affiliated with transport ports in certain tunneling scenarios. Locators may simply be traditional network addresses. The format of the locator fields in the LOCATOR parameter is defined in Section 4. RFC 5206 HIP Mobility and Multihoming April 2008 3.1.3. Multihoming Overview A related operational configuration is host multihoming, in which a host has multiple locators simultaneously rather than sequentially, as in the case of mobility. By using the LOCATOR parameter defined herein, a host can inform its peers of additional (multiple) locators at which it can be reached, and can declare a particular locator as a "preferred" locator. Although this document defines a basic mechanism for multihoming, it does not define detailed policies and procedures, such as which locators to choose when more than one pair is available, the operation of simultaneous mobility and multihoming, source address selection policies (beyond those specified in [RFC3484]), and the implications of multihoming on transport protocols and ESP anti-replay windows. Additional definitions of HIP-based multihoming are expected to be part of future documents. RFC 5206 HIP Mobility and Multihoming April 2008 In this section, we briefly introduce a number of usage scenarios for HIP mobility and multihoming. These scenarios assume that HIP is being used with the ESP transform [RFC5202], although other scenarios may be defined in the future. To understand these usage scenarios, the reader should be at least minimally familiar with the HIP protocol specification [RFC5201]. However, for the (relatively) uninitiated reader, it is most important to keep in mind that in HIP the actual payload traffic is protected with ESP, and that the ESP SPI acts as an index to the right host-to-host context. More specification details are found later in Section 4 and Section 5. The readdressing protocol is an asymmetric protocol where a mobile or multihomed host informs a peer host about changes of IP addresses on affected SPIs. The readdressing exchange is designed to be piggybacked on existing HIP exchanges. The majority of the packets on which the LOCATOR parameters are expected to be carried are UPDATE packets. However, some implementations may want to experiment with sending LOCATOR parameters also on other packets, such as R1, I2, and NOTIFY. RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 3.2.3. Host Multihoming RFC 5206 HIP Mobility and Multihoming April 2008 In the multihoming case, the sender may also have multiple valid locators from which to source traffic. In practice, a HIP association in a multihoming configuration may have both a preferred peer locator and a preferred local locator, although rules for source address selection should ultimately govern the selection of the source locator based on the destination locator. Consider the case between two hosts, one single-homed and one multihomed. The multihomed host may decide to inform the single- homed host about its other address. It is RECOMMENDED that the multihomed host set up a new SA pair for use on this new address. To do this, the multihomed host sends a LOCATOR with an ESP_INFO, indicating the request for a new SA by setting the OLD SPI value to zero, and the NEW SPI value to the newly created incoming SPI. A Locator Type of "1" is used to associate the new address with the new SPI. The LOCATOR parameter also contains a second Type "1" locator, that of the original address and SPI. To simplify parameter processing and avoid explicit protocol extensions to remove locators, each LOCATOR parameter MUST list all locators in use on a connection (a complete listing of inbound locators and SPIs for the host). The multihomed host waits for an ESP_INFO (new outbound SA) from the peer and an ACK of its own UPDATE. As in the mobility case, the peer host must perform an address verification before actively using the new address. Figure 5 illustrates this scenario. RFC 5206 HIP Mobility and Multihoming April 2008 Figure 5: Basic Multihoming Scenario In multihoming scenarios, it is important that hosts receiving UPDATEs associate them correctly with the destination address used in the packet carrying the UPDATE. When processing inbound LOCATORs that establish new security associations on an interface with multiple addresses, a host uses the destination address of the UPDATE containing the LOCATOR as the local address to which the LOCATOR plus ESP_INFO is targeted. This is because hosts may send UPDATEs with the same (locator) IP address to different peer addresses -- this has the effect of creating multiple inbound SAs implicitly affiliated with different peer source addresses. 3.2.4. Site Multihoming This case is handled the same as if there were different IP addresses, described above in Section 3.2.3. Note that a single interface may experience site multihoming while the host itself may have multiple interfaces. Note that a host may be multihomed and mobile simultaneously, and that a multihomed host may want to protect the location of some of its interfaces while revealing the real IP address of some others. This document does not presently specify additional site multihoming extensions to HIP; further alignment with the IETF shim6 working group may be considered in the future. RFC 5206 HIP Mobility and Multihoming April 2008 3.2.5. Dual host multihoming Figure 6: Dual Multihoming Case in Which Each Host Uses LOCATOR to Add a Second Address 3.2.6. Combined Mobility and Multihoming It looks likely that in the future, many mobile hosts will be simultaneously mobile and multihomed, i.e., have multiple mobile interfaces. Furthermore, if the interfaces use different access technologies, it is fairly likely that one of the interfaces may appear stable (retain its current IP address) while some other(s) may experience mobility (undergo IP address change). RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 Figure 9 illustrates Credit-Based Authorization: Host B measures the amount of data recently received from peer A and, when A readdresses, sends packets to A's new, unverified address as long as the sum of the packet sizes does not exceed the measured, received data volume. When insufficient credit is left, B stops sending further packets to A until A's address becomes ACTIVE. The address changes may be due to mobility, multihoming, or any other reason. Not shown in Figure 9 are the results of credit aging (Section 5.6.2), a mechanism used to dampen possible time-shifting attacks. RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 A host may establish any number of security associations (or SPIs) with a peer. The main purpose of having multiple SPIs with a peer is to group the addresses into collections that are likely to experience fate sharing. For example, if the host needs to change its addresses on SPI2, it is likely that both address21 and address22 will simultaneously become obsolete. In a typical case, such SPIs may correspond with physical interfaces; see below. Note, however, that especially in the case of site multihoming, one of the addresses may become unreachable while the other one still works. In the typical case, however, this does not require the host to inform its peers about the situation, since even the non-working address still logically exists. RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 Once the host has decided on the groups and assignment of addresses to the SPIs, it creates a LOCATOR parameter that serves as a complete representation of the addresses and affiliated SPIs intended for active use. We now describe a few cases introduced in Section 3.2. We assume that the Traffic Type for each locator is set to "0" (other values for Traffic Type may be specified in documents that separate the HIP control plane from data plane traffic). Other mobility and multihoming cases are possible but are left for further experimentation. 1. Host mobility with no multihoming and no rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter. The ESP_INFO contains the current value of the SPI in both the OLD SPI and NEW SPI fields. The LOCATOR contains a single Locator with a "Locator Type" of "1"; RFC 5206 HIP Mobility and Multihoming April 2008 2. Host mobility with no multihoming but with rekeying. The mobile host creates a single UPDATE containing a single ESP_INFO with a single LOCATOR parameter (with a single address). The ESP_INFO contains the current value of the SPI in the OLD SPI and the new value of the SPI in the NEW SPI, and a KEYMAT Index as selected by local policy. Optionally, the host may choose to initiate a Diffie Hellman rekey by including a DIFFIE_HELLMAN parameter. The LOCATOR contains a single Locator with "Locator Type" of "1"; the SPI must match that of the NEW SPI in the ESP_INFO. Otherwise, the steps are identical to the case in which no rekeying is initiated. 3. Host multihoming (addition of an address). We only describe the simple case of adding an additional address to a (previously) single-homed, non-mobile host. The host SHOULD set up a new SA pair between this new address and the preferred address of the peer host. To do this, the multihomed host creates a new inbound SA and creates a new SPI. For the outgoing UPDATE message, it inserts an ESP_INFO parameter with an OLD SPI field of "0", a NEW SPI field corresponding to the new SPI, and a KEYMAT Index as selected by local policy. The host adds to the UPDATE message a LOCATOR with two Type "1" Locators: the original address and SPI active on the association, and the new address and new SPI being added (with the SPI matching the NEW SPI contained in the ESP_INFO). The Preferred bit SHOULD be set depending on the policy to tell the peer host which of the two locators is preferred. The UPDATE also contains a SEQ parameter and optionally a DIFFIE_HELLMAN parameter, and follows rekeying procedures with respect to this new address. The UPDATE message SHOULD be sent to the peer's Preferred address with a source address corresponding to the new locator. RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 RFC 5206 HIP Mobility and Multihoming April 2008 http://www.ietf.org/rfc/rfc5207.txt 5207 NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication. M. Stiemerling, J. Quittek, L. Eggert. April 2008. (Format: TXT=3D27873 bytes) (Status: INFORMATIONAL) The proposed mobility management packet exchange [RFC5206] [NIKANDER] can support this method of NAT traversal. The original intention of this extension is to support host mobility and multihoming. This mechanism is similar to the Alternate Network Address Types (ANAT) described in [RFC4091]. However, HIP peers use mobility management messages to notify peers about rendezvous points, similar to [RFC4091]. HIP peers must determine their contact address before they can announce it to their peers. Possible solutions for signaling SPI values are the mechanisms proposed in the IETF NSIS WG (NATFW NSLP) and MIDCOM MIB module [RFC5190]. Using MIDCOM in the context of HIP requires additional knowledge about network topology. For example, in multihomed environments with different border NATs or firewalls, a host must know which of the multiple NATs/firewalls to signal. Therefore, this solution can be problematic. [RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. http://www.ietf.org/rfc/rfc5210.txt 5210 A Source Address Validation Architecture (SAVA) Testbed and Deployment Experience. J. Wu, J. Bi, X. Li, G. Ren, K. Xu, M. Williams. June 2008. (Format: TXT=3D58363 bytes) (Status: = EXPERIMENTAL) Finally, all the presented solutions have issues in situations that go beyond a simple model of a host connecting to a network via the same single interface at all times. Multihoming, failover, and some forms of mobility or wireless solutions may collide with the requirements of source address validation. In general, dynamic changes to the attachment of hosts and topology of the routing infrastructure are something that would have to be handled in a production environment. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5213.txt 5213 Proxy Mobile IPv6. S. Gundavelli, Ed., K. Leung, V. Devarapalli, K. Chowdhury, B. Patil. August 2008. (Format: TXT=3D226902 bytes) (Status: PROPOSED STANDARD) 1. Introduction ................................................. 4 2. Conventions and Terminology ................................. 5 2.1. Conventions Used in This Document ....................... 5 2.2. Terminology ............................................. 5 3. Proxy Mobile IPv6 Protocol Overview ......................... 9 4. Proxy Mobile IPv6 Protocol Security ......................... 15 4.1. Peer Authorization Database (PAD) Example Entries ....... 16 4.2. Security Policy Database (SPD) Example Entries ........... 17 5. Local Mobility Anchor Operation ............................. 17 5.1. Extensions to Binding Cache Entry Data Structure ......... 18 5.2. Supported Home Network Prefix Models ..................... 19 5.3. Signaling Considerations ................................. 20 5.3.1. Processing Proxy Binding Updates ..................... 20 5.3.2. Initial Binding Registration (New Mobility Session) .. 22 5.3.3. Binding Lifetime Extension (No Handoff) ............. 23 5.3.4. Binding Lifetime Extension (After Handoff) ........... 24 5.3.5. Binding De-Registration ............................. 24 5.3.6. Constructing the Proxy Binding Acknowledgement Message ............................................. 25 5.4. Multihoming Support ..................................... 27 5.4.1. Binding Cache Entry Lookup Considerations ........... 28 5.5. Timestamp Option for Message Ordering ................... 34 5.6. Routing Considerations ................................... 37 5.6.1. Bi-Directional Tunnel Management ..................... 37 5.6.2. Forwarding Considerations ........................... 38 5.6.3. Explicit Congestion Notification (ECN) Considerations for Proxy Mobile IPv6 Tunnels ......... 39 5.7. Local Mobility Anchor Address Discovery ................. 40 5.8. Mobile Prefix Discovery Considerations ................... 40 5.9. Route Optimization Considerations ....................... 41 6. Mobile Access Gateway Operation ............................. 41 6.1. Extensions to Binding Update List Entry Data Structure ... 42 6.2. Mobile Node's Policy Profile ............................. 43 6.3. Supported Access Link Types ............................. 44 6.4. Supported Address Configuration Modes ................... 44 6.5. Access Authentication and Mobile Node Identification ..... 45 6.6. Acquiring Mobile Node's Identifier ....................... 45 6.7. Home Network Emulation ................................... 46 6.8. Link-local and Global Address Uniqueness ................. 46 6.9. Signaling Considerations ................................. 48 6.9.1. Binding Registrations ............................... 48 6.9.2. Router Solicitation Messages ......................... 56 6.9.3. Default-Router ....................................... 57 6.9.4. Retransmissions and Rate Limiting ................... 58 6.9.5. Path MTU Discovery ................................... 59 6.10. Routing Considerations ................................... 60 Multihomed Mobile Node A mobile node that connects to the same Proxy Mobile IPv6 domain through more than one interface and uses these interfaces simultaneously is referred to as a multihomed mobile node. 5.4. Multihoming Support This specification allows mobile nodes to connect to a Proxy Mobile IPv6 domain through multiple interfaces for simultaneous access. The following are the key aspects of this multihoming support. There can be multiple Binding Cache entries for a given mobile node. When doing a lookup for a mobile node's Binding Cache entry for processing a received Proxy Binding Update message, the local mobility anchor MUST apply the following multihoming considerations (in the below specified order, starting with Section 5.4.1.1). These rules are chained with the processing rules specified in Section 5.3. http://www.ietf.org/rfc/rfc5245.txt 5245 Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. J. Rosenberg. April 2010. (Format: TXT=3D285120 bytes) (Obsoletes RFC4091, RFC4092) (Status: PROPOSED STANDARD) This specification defines Interactive Connectivity Establishment (ICE) as a technique for NAT traversal for UDP-based media streams (though ICE can be extended to handle other transport protocols, such as TCP [ICE-TCP]) established by the offer/answer model. ICE is an extension to the offer/answer model, and works by including a multiplicity of IP addresses and ports in SDP offers and answers, which are then tested for connectivity by peer-to-peer connectivity checks. The IP addresses and ports included in the SDP and the connectivity checks are performed using the revised STUN specification [RFC5389], now renamed to Session Traversal Utilities for NAT. The new name and new specification reflect its new role as a tool that is used with other NAT traversal techniques (namely ICE) rather than a standalone NAT traversal solution, as the original STUN specification was. ICE also makes use of Traversal Using Relays around NAT (TURN) [RFC5766], an extension to STUN. Because ICE exchanges a multiplicity of IP addresses and ports for each media stream, it also allows for address selection for multihomed and dual- stack hosts, and for this reason it deprecates RFC 4091 [RFC4091] and [RFC4092]. If an agent is multihomed, it obtains a candidate from each IP address. Depending on the location of the PEER (the other agent in the session) on the IP network relative to the agent, the agent may be reachable by the peer through one or more of those IP addresses. Consider, for example, an agent that has a local IP address on a private net 10 network (I1), and a second connected to the public Internet (I2). A candidate from I1 will be directly reachable when communicating with a peer on the same private net 10 network, while a candidate from I2 will be directly reachable when communicating with a peer on the public Internet. Rather than trying to guess which IP address will work prior to sending an offer, the offering agent includes both candidates in its offer. Agents SHOULD obtain relayed candidates and SHOULD obtain server reflexive candidates. These requirements are at SHOULD strength to allow for provider variation. Use of STUN and TURN servers may be unnecessary in closed networks where agents are never connected to the public Internet or to endpoints outside of the closed network. In such cases, a full implementation would be used for agents that are dual stack or multihomed, to select a host candidate. Use of TURN servers is expensive, and when ICE is being used, they will only be utilized when both endpoints are behind NATs that perform address and port dependent mapping. Consequently, some deployments might consider this use case to be marginal, and elect not to use TURN servers. If an agent does not gather server reflexive or relayed candidates, it is RECOMMENDED that the functionality be implemented and just disabled through configuration, so that it can be re-enabled through configuration if conditions change in the future. When using the formula, an agent computes the priority by determining a preference for each type of candidate (server reflexive, peer reflexive, relayed, and host), and, when the agent is multihomed, choosing a preference for its IP addresses. These two preferences are then combined to compute the priority for a candidate. That priority is computed using the following formula: The local preference MUST be an integer from 0 to 65535 inclusive. It represents a preference for the particular IP address from which the candidate was obtained, in cases where an agent is multihomed. 65535 represents the highest preference, and a zero, the lowest. When there is only a single IP address, this value SHOULD be set to 65535. More generally, if there are multiple candidates for a particular component for a particular media stream that have the same type, the local preference MUST be unique for each one. In this specification, this only happens for multihomed hosts. If a host is multihomed because it is dual stack, the local preference SHOULD be set equal to the precedence value for IP addresses described in RFC 3484 [RFC3484]. candidate, it will first transit the media intermediary before being received. Relayed candidates are one type of candidate that involves a media intermediary. Another are host candidates obtained from a VPN interface. When media is transited through a media intermediary, it can increase the latency between transmission and reception. It can increase the packet losses, because of the additional router hops that may be taken. It may increase the cost of providing service, since media will be routed in and right back out of a media intermediary run by a provider. If these concerns are important, the type preference for relayed candidates SHOULD be lower than host candidates. The RECOMMENDED values are 126 for host candidates, 100 for server reflexive candidates, 110 for peer reflexive candidates, and 0 for relayed candidates. Furthermore, if an agent is multihomed and has multiple IP addresses, the local preference for host candidates from a VPN interface SHOULD have a priority of 0. In this case, the offerer is multihomed. It has one IP address, 10.0.1.100, on network C, which is a net 10 private network. The answerer is on this same network. The offerer is also connected to network A, which is 192.168/16. The offerer has an IP address of 192.168.1.100 on this network. There is a NAT on this network, natting into network B, which is another net 10 private network, but not connected to network C. There is a STUN server on network B. http://www.ietf.org/rfc/rfc5265.txt 5265 Mobile IPv4 Traversal across IPsec-Based VPN Gateways. S. Vaarala, E. Klovning. June 2008. (Format: TXT=3D86254 bytes) = (Status: PROPOSED STANDARD) The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification. The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] provides better mobility for IPsec. This would allow the external Mobile IPv4 layer described in this specification to be removed. However, deploying MOBIKE requires changes to VPN devices, and is thus out of scope of this specification. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc5266.txt 5266 Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE). V. Devarapalli, P. Eronen. June 2008. (Format: TXT=3D33186 bytes) (Also BCP0136) (Status: BEST = CURRENT PRACTICE) Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc5294.txt 5294 Host Threats to Protocol Independent Multicast (PIM). P. Savola, J. Lingard. August 2008. (Format: TXT=3D26525 bytes) (Status: INFORMATIONAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5321.txt 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT=3D225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: DRAFT STANDARD) When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the SMTP client SHOULD try at least two addresses. Two types of information are used to rank the host addresses: multiple MX records, and multihomed hosts. The destination host (perhaps taken from the preferred MX record) may be multihomed, in which case the domain name resolver will return a list of alternative IP addresses. It is the responsibility of the domain name resolver interface to have ordered this list by decreasing preference if necessary, and the SMTP sender MUST try them in the order presented. Although the capability to try multiple alternative addresses is required, specific installations may want to limit or disable the use of alternative addresses. The question of whether a sender should attempt retries using the different addresses of a multihomed host has been controversial. The main argument for using the multiple addresses is that it maximizes the probability of timely delivery, and indeed sometimes the probability of any delivery; the counter- argument is that it may result in unnecessary resource use. Note that resource use is also strongly determined by the sending strategy discussed in Section 4.5.4.1. In the contemporary Internet, SMTP clients and servers may be hosted on IPv4 systems, IPv6 systems, or dual-stack systems that are compatible with either version of the Internet Protocol. The host domains to which MX records point may, consequently, contain "A RR"s (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC 3974 [39] discusses some operational experience in mixed environments, it was not comprehensive enough to justify standardization, and some of its recommendations appear to be inconsistent with this specification. The appropriate actions to be taken either will depend on local circumstances, such as performance of the relevant networks and any conversions that might be necessary, or will be obvious (e.g., an IPv6-only client need not attempt to look up A RRs or attempt to reach IPv4-only servers). Designers of SMTP implementations that might run in IPv6 or dual-stack environments should study the procedures above, especially the comments about multihomed hosts, and, preferably, provide mechanisms to facilitate operational tuning and mail interoperability between IPv4 and IPv6 systems while considering local circumstances. http://www.ietf.org/rfc/rfc5338.txt 5338 Using the Host Identity Protocol with Legacy Applications. T. Henderson, P. Nikander, M. Komu. September 2008. (Format: TXT=3D34882= bytes) (Status: EXPERIMENTAL) When a host has multiple HIs and the socket behavior does not prescribe the use of any particular HI as a local identifier, it is a matter of local policy as to how to select a HI to serve as a local identifier. However, systems that bind to a wildcard may face problems when multiple HITs or LSIs are defined. These problems are not specific to HIP per se, but are also encountered in non-HIP multihoming scenarios with applications not designed for multihoming. Reimplementing the server application using the sendmsg() and recvmsg() to support multihoming (particularly considering the ancillary data) would be the ultimate solution to this problem, but with legacy applications is not an option. As a workaround, we make suggestion for servers providing UDP-based services with non- multihoming-capable services. Such servers should announce only the HIT or public key that matches to the default outgoing HIT of the host to avoid such problems. http://www.ietf.org/rfc/rfc5358.txt 5358 Preventing Use of Recursive Nameservers in Reflector Attacks. J. Damas, F. Neves. October 2008. (Format: TXT=3D14957 bytes) (Also BCP0140) (Status: BEST CURRENT PRACTICE) Even with all these recommendations, network operators should consider deployment of ingress filtering [BCP38] in routers to prevent use of address spoofing as a viable course of action. In situations where more complex network setups are in place, "Ingress Filtering for Multihomed Network" [BCP84] maybe a useful additional reference. [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5363.txt 5363 Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services. G. Camarillo, A.B. Roach. October 2008. (Format: TXT=3D22912 bytes) (Status: PROPOSED STANDARD) In any case, note that this problem is not specific to SIP URI- list services; it also appears in scenarios that relate to multihoming where a server needs to contact a set of IP addresses provided by a client. http://www.ietf.org/rfc/rfc5375.txt 5375 IPv6 Unicast Address Assignment Considerations. G. Van de Velde, C. Popoviciu, T. Chown, O. Bonness, C. Hahn. December 2008. = (Format: TXT=3D83809 bytes) (Status: INFORMATIONAL) However, a multihomed site may deploy addresses from two or more service-provider-assigned IPv6 address ranges. Here, the network administrator must have awareness on where and how these ranges are used on the multihomed infrastructure environment. The nature of the usage of multiple prefixes may depend on the reason for multihoming (e.g., resilience failover, load balancing, policy-based routing, or multihoming during an IPv6 renumbering event). IPv6 introduces improved support for multi-addressed hosts through the IPv6 default address selection methods described in RFC 3484 [RFC3484]. A multihomed host may thus have two or more addresses, one per prefix (provider), and select source and destination addresses to use as described in that RFC. However, multihoming also has some operational and administrative burdens besides choosing multiple addresses per interface [RFC4218] [RFC4219]. Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes. [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers Should Think About", RFC 4219, October 2005. [SHIM6] IETF, "Site Multihoming by IPv6 Intermediation (shim6) Charter", . No ULA addressing is used on site. The campus is not multihomed (JANET is the sole provider), nor does it expect to change service provider, and thus does not plan to use ULAs for the (perceived) benefit of easing network renumbering. Indeed, the campus has renumbered following the aforementioned renumbering procedure [RFC4192] on two occasions, and this has proven adequate (with provisos documented in [THINKABOUT]). The campus does not see any need to deploy ULAs for in-band or out-of-band network management; there are enough IPv6 prefixes available in the site allocation for the infrastructure. In some cases, use of private IP address space in IPv4 creates problems, so University of Southampton believes that the availability of ample global IPv6 address space for infrastructure may be a benefit for many sites. o The IPv6 addressing schema of the SP must deal with multiple attachments of a single customer to the SP network infrastructure (i.e., multihomed network access with the same SP). A.2.3.3. POP Multihoming POP multihoming (or better, LER multihoming) of customers with the same SP can be realized within the proposed IPv6 addressing schema of the SP by assigning multiple LER-dependent prefixes to this customer (i.e., considering each customer location as a single customer) or by choosing a customer prefix out of the pool of "big" customers. The second solution has the disadvantage that in every LER where the customer is attached, this prefix will appear inside the IGP routing table, thus requiring an explicit MPLS label. Note: The negative effects (described above) of POP/LER multihoming on the addressing architecture in the SP access network are not resolved by implementing the Site Multihoming by IPv6 Intermediation (SHIM6) approach. SHIM6 only targets a mechanism for dealing with multiple prefixes in end systems. The SP is expected to have unaggregated customer prefixes in its internal routing tables. http://www.ietf.org/rfc/rfc5387.txt 5387 Problem and Applicability Statement for Better-Than-Nothing Security (BTNS). J. Touch, D. Black, Y. Wang. November 2008. = (Format: TXT=3D71707 bytes) (Status: INFORMATIONAL) o the ability of multihoming to cause one network-layer source of traffic to appear to be multiple sources (potentially triggering unexpected warnings and requiring re-acceptance of the same BTNS credential), and http://www.ietf.org/rfc/rfc5424.txt 5424 The Syslog Protocol. R. Gerhards. March 2009. (Format: TXT=3D85162 bytes) (Obsoletes RFC3164) (Status: PROPOSED STANDARD) This parameter can be used to provide identifying information in addition to what is present in the HOSTNAME field. It might be especially useful if the host's IP address is included in the message while the HOSTNAME field still contains the FQDN. It is also useful for describing all IP addresses of a multihomed host. http://www.ietf.org/rfc/rfc5439.txt 5439 An Analysis of Scaling Issues in MPLS-TE Core Networks. S. Yasukawa, A. Farrel, O. Komolafe. February 2009. (Format: TXT=3D93845= bytes) (Status: INFORMATIONAL) a. Multihoming It is relatively common for a node at level (n) to be attached to more than one node at level (n-1). This is particularly common at PEs that may be connected to more than one P(n). Furthermore, in multihoming scenarios where each PE is connected to more than one P(n) or where a PE has multiple links to a single P(n), there may be a desire to pre-select the link to be used and to direct the traffic to that link using a PE-PE LSP. Note that multihoming has not been considered in this document. http://www.ietf.org/rfc/rfc5454.txt 5454 Dual-Stack Mobile IPv4. G. Tsirtsis, V. Park, H. Soliman. March 2009. (Format: TXT=3D38606 bytes) (Status: PROPOSED STANDARD) [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008. http://www.ietf.org/rfc/rfc5461.txt 5461 TCP's Reaction to Soft Errors. F. Gont. February 2009. (Format: TXT=3D31749 bytes) (Status: INFORMATIONAL) This document analyzes the problems that may arise due to TCP's fault recovery reactions to ICMP soft errors. It analyzes the problems that may arise when a host tries to establish a TCP connection with a multihomed host that has some unreachable addresses. Additionally, it analyzes the problems that may arise in the specific scenario where dual-stack nodes that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 and IPv6 environments. http://www.ietf.org/rfc/rfc5474.txt 5474 A Framework for Packet Selection and Reporting. N. Duffield, Ed., D. Chiou, B. Claise, A. Greenberg, M. Grossglauser, J. Rexford. = March 2009. (Format: TXT=3D86080 bytes) (Status: INFORMATIONAL) In certain circumstances, precise information about the spatial flow of traffic through the network domain is required to detect and diagnose problems and verify correct network behavior. In the case of the overloaded link, it would be very helpful to know the precise set of paths that packets traversing this link follow. This would readily reveal a routing problem such as a loop, or a link with a misconfigured weight. More generally, complex diagnosis scenarios can benefit from measurement of traffic intensities (and other attributes) over a set of paths that is constrained in some way. For example, if a multihomed customer complains about performance problems on one of the access links from a particular source address prefix, the operator should be able to examine in detail the traffic from that source prefix that also traverses the specified access link towards the customer. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5475.txt 5475 Sampling and Filtering Techniques for IP Packet Selection. T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. Raspall. March = 2009. (Format: TXT=3D101260 bytes) (Status: PROPOSED STANDARD) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5522.txt 5522 Network Mobility Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks. W. Eddy, = W. Ivancic, T. Davis. October 2009. (Format: TXT=3D79570 bytes) = (Status: INFORMATIONAL) 1. Introduction ....................................................2 2. NEMO RO Scenarios ...............................................5 2.1. Aeronautical Communications Scenarios ......................5 2.1.1. Air Traffic Services Domain .........................6 2.1.2. Airline Operational Services Domain .................8 2.1.3. Passenger Services Domain ...........................9 2.2. Space Exploration Scenarios ...............................10 3. Required Characteristics .......................................12 3.1. Req1 - Separability .......................................13 3.2. Req2 - Multihoming ........................................14 3.3. Req3 - Latency ............................................15 3.4. Req4 - Availability .......................................16 3.5. Req5 - Packet Loss ........................................17 3.6. Req6 - Scalability ........................................18 3.7. Req7 - Efficient Signaling ................................19 3.8. Req8 - Security ...........................................20 3.9. Req9 - Adaptability .......................................22 4. Desirable Characteristics ......................................22 4.1. Des1 - Configuration ......................................22 4.2. Des2 - Nesting ............................................23 4.3. Des3 - System Impact ......................................23 4.4. Des4 - VMN Support ........................................23 4.5. Des5 - Generality .........................................24 5. Security Considerations ........................................24 6. Acknowledgments ................................................24 7. References .....................................................25 7.1. Normative References ......................................25 7.2. Informative References ....................................25 Appendix A. Basics of IP-Based Aeronautical Networking ........28 Appendix B. Basics of IP-based Space Networking ................30 An MR used for ATS will be capable of using multiple data links (at least VHF-based, satellite, HF-based, and wired), and will likely be supported by a backup unit in the case of failure, leading to a case of a multihomed MR that is at least multi-interfaced and possibly multi-prefixed as well, in NEMO terminology. It can be assumed that for manned spaceflight, at least multiple MRs will be present and online simultaneously for fast failover. These will usually be multihomed over space links in diverse frequency bands, and so multiple access network prefixes can be expected to be in use simultaneously, especially since some links will be direct to ground stations while others may be bent-pipe repeated through satellite relays like the Tracking and Data Relay Satellite System (TDRSS). This conforms to the (n,1,1) or (n,n,1) NEMO multihoming scenarios [12]. For unmanned missions, if low weight and power are more critical, it is likely that only a single MR and single link/ prefix may be present, conforming to the (1,1,1) or (1,n,1) NEMO multihoming scenarios [12]. 3.2. Req2 - Multihoming 3.2.1. Rationale for Aeronautics - Multihoming Multiple factors drive a requirement for multihoming capabilities. For ATS safety-of-life critical traffic, the need for high availability suggests a basic multihoming requirement. The It is not this requirement's intention that an RO scheme itself provide multihoming, but rather simply to exclude RO techniques whose use is not possible in multihomed scenarios. In terms of NEMO multihoming scenarios [12], it MUST be possible to support at least the (n,1,n) and (n,n,n) scenarios. [12] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. http://www.ietf.org/rfc/rfc5533.txt 5533 Shim6: Level 3 Multihoming Shim Protocol for IPv6. E. Nordmark, M. Bagnulo. June 2009. (Format: TXT=3D299931 bytes) (Status: = PROPOSED STANDARD) Shim6: Level 3 Multihoming Shim Protocol for IPv6 This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working. This document describes a layer 3 shim approach and protocol for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties [11], without assuming that a multihomed site will have a provider-independent IPv6 address announced in the global IPv6 routing table. The hosts in a site that has multiple provider- allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working (the term locator is defined in Section 2). The Shim6 protocol is a site-multihoming solution in the sense that it allows existing communication to continue when a site that has multiple connections to the Internet experiences an outage on a subset of these connections or further upstream. However, Shim6 processing is performed in individual hosts rather than through site- wide mechanisms. The problem we are trying to solve is site multihoming, with the ability to have the set of site prefixes change over time due to site renumbering. Further, we assume that such changes to the set of locator prefixes can be relatively slow and managed: slow enough to allow updates to the DNS to propagate (since the protocol defined in this document depends on the DNS to find the appropriate locator sets). However, note that it is an explicit non-goal to make communication survive a renumbering event (which causes all the locators of a host to change to a new set of locators). This proposal does not attempt to solve the related problem of host Finally, this proposal also does not try to provide a new network- level or transport-level identifier name space distinct from the current IP address name space. Even though such a concept would be useful to upper-layer protocols (ULPs) and applications, especially if the management burden for such a name space was negligible and there was an efficient yet secure mechanism to map from identifiers to locators, such a name space isn't necessary (and furthermore doesn't seem to help) to solve the multihoming problem. This implies that the ULID selection is performed as today's default address selection as specified in RFC 3484 [7]. Some extensions are needed to RFC 3484 to try different source addresses, whether or not the Shim6 protocol is used, as outlined in [9]. Underneath, and transparently, the multihoming shim selects working locator pairs with the initial locator pair being the ULID pair. If communication subsequently fails, the shim can test and select alternate locators. A subsequent section discusses the issues that arise when the selected ULID is not initially working, which creates the need to switch locators up front. There has been some discussion of using non-routable addresses, such as Unique-Local Addresses (ULAs) [14], as ULIDs in a multihoming solution. While this document doesn't specify all aspects of this, it is believed that the approach can be extended to handle the non- routable address case. For example, the protocol already needs to handle ULIDs that are not initially reachable. Thus, the same mechanism can handle ULIDs that are permanently unreachable from outside their site. The issue becomes how to make the protocol perform well when the ULID is known a priori to be unreachable (e.g., the ULID is a ULA), for instance, avoiding any timeout and retries in this case. In addition, one would need to understand how the ULAs would be entered in the DNS to avoid a performance impact on existing, non-Shim6-aware IPv6 hosts potentially trying to communicate to the (unreachable) ULA. The proposal uses a multihoming shim layer within the IP layer, i.e., below the ULPs, as shown in Figure 1, in order to provide ULP independence. The multihoming shim layer behaves as if it is associated with an extension header, which would be placed after any routing-related headers in the packet (such as any hop-by-hop options). However, when the locator pair is the ULID pair, there is no data that needs to be carried in an extension header; thus, none is needed in that case. Layering the Fragmentation header above the multihoming shim makes reassembly robust in the case that there is broken multi-path routing that results in using different paths, hence potentially different source locators, for different fragments. Thus, the multihoming shim layer is placed between the IP endpoint sublayer (which handles fragmentation and reassembly) and the IP routing sublayer (which selects the next hop and interface to use for sending out packets). ---------------------------- ---------------------------- | Sender A | | Receiver B | | | | | | ULP | | ULP | | | src ULID(A)=3DL1(A) | | ^ | | | dst ULID(B)=3DL1(B) | | | src ULID(A)=3DL1(A) = | | v | | | dst ULID(B)=3DL1(B) | | multihoming shim | | multihoming shim | | | src L2(A) | | ^ | | | dst L3(B) | | | src L2(A) | | v | | | dst L3(B) | | IP | | IP | ---------------------------- ---------------------------- | ^ ------- cloud with some routers ------- Inherent in a scalable multihoming mechanism that separates the locator function of the IP address from identifying function of the IP address is that each host ends up with multiple locators. This means that, at least for initial contact, it is the remote peer application (or layer working on its behalf) that needs to select an initial ULID, which automatically becomes the initial locator. In the case of Shim6, this is performed by applying RFC 3484 address selection. This is quite different than the common case of IPv4 multihoming where the site has a single IP address prefix, since in that case the peer performs no destination address selection. Thus, in "single prefix multihoming", the site (and in many cases its upstream ISPs) can use BGP to exert some control of the ingress path used to reach the site. This capability does not by itself exist in "multiple prefix multihoming" approaches such as Shim6. It is conceivable that extensions allowing site or provider guidance of host-based mechanisms could be developed. But it should be noted that traffic engineering via BGP, MPLS, or other similar techniques can still be applied for traffic on each individual prefix; Shim6 does not remove the capability for this. It does provide some additional capabilities for hosts to choose between prefixes. ULID-pair context The state that the multihoming shim maintains between a pair of upper-layer identifiers. The context is identified by a Context Tag for each direction of the communication and also by a ULID-pair and a Forked Instance Identifier (see below). Address and prefix configuration: The Shim6 protocol assumes that, in a multihomed site, multiple prefixes will be available. Such configuration can increase the operation work in a network. However, it should be noted that the capability of having multiple prefixes in a site and multiple addresses assigned to an interface is an IPv6 capability that goes beyond the Shim6 case, and it is expected to be widely used. So, even though this is the case for Shim6, we consider that the implications of such a configuration is beyond the particular case of Shim6 and must be addressed for the generic IPv6 case. Nevertheless, Shim6 also assumes the usage of CGA/HBA addresses by Shim6 hosts. This implies that Shim6-capable hosts should configure addresses using HBA/CGA generation mechanisms. Additional consideration about this issue can be found at [19]. The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, addresses incorporate a cryptographic one-way hash of the prefix set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using the shim protocol node can efficiently verify that the alternative addresses proposed for continuing the communication are bound to the initial address through a simple hash calculation. [4] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009. [8] Nordmark, E., "Multihoming without IP Identifiers", Work in Progress, July 2004. [9] Bagnulo, M., "Updating RFC 3484 for multihoming support", Work in Progress, November 2007. [11] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- Multihoming Architectures", RFC 3582, August 2003. [15] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. [16] Huitema, C., "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, September 2005. [19] Bagnulo, M. and J. Abley, "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", Work in Progress, July 2007. [23] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket Application Program Interface (API) for Multihoming Shim", Work in Progress, November 2008. In order to cope with the identified limitations, an alternative approach that does not constrain the Flow Label values that are used by communications using ULIDs equal to the locators (i.e., no shim translation) is to only require that different Flow Label values are assigned to different shim contexts. In such an approach, communications start with unmodified Flow Label usage (could be zero or as suggested in [12]). The packets sent after a failure when a different locator pair is used would use a completely different Flow Label, and this Flow Label could be allocated by the receiver as part of the shim context establishment. Since it is allocated during the context establishment, the receiver of the "failed over" packets can pick a Flow Label of its choosing (that is unique in the sense that no other context is using it as a Context Tag), without any performance impact, respecting that, for each locator pair, the Flow Label value used for a given locator pair doesn't change due to the operation of the multihoming shim. Another option that was discussed during the design of this protocol was the possibility of using IPsec for protecting the shim protocol. Now, the problem under consideration in this scenario is how to securely bind an address that is being used as ULID with a locator set that can be used to exchange packets. The mechanism provided by IPsec to securely bind the address that is used with cryptographic keys is the usage of digital certificates. This implies that an IPsec-based solution would require a common and mutually trusted third party to generate digital certificates that bind the key and the ULID. Considering that the scope of application of the shim protocol is global, this would imply a global public key infrastructure (PKI). The major issues with this approach are the deployment difficulties associated with a global PKI. The other possibility would be to use some form of opportunistic IPSec, like Better-Than-Nothing-Security (BTNS) [22]. However, this would still present some issues. In particular, this approach requires a leap- of-faith in order to bind a given address to the public key that is being used, which would actually prevent the most critical security feature that a Shim6 security solution needs to achieve from being provided: proving identifier ownership. On top of that, using IPsec would require to turn on per-packet AH/ESP just for multihoming to occur. In general, SHIM6 was expected to work between pairs of hosts that have no prior arrangement, security association, or common, trusted third party. It was also seen as undesirable to have to turn on per- packet AH/ESP just for the multihoming to occur. However, Shim6 should work and have an additional level of security where two hosts choose to use IPsec. The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, http://www.ietf.org/rfc/rfc5534.txt 5534 Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming. J. Arkko, I. van Beijnum. June 2009. (Format: = TXT=3D88152 bytes) (Status: PROPOSED STANDARD) Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found. The Shim6 protocol [RFC5533] extends IPv6 to support multihoming. It is an IP-layer mechanism that hides multihoming from applications. A part of the Shim6 solution involves detecting when a currently used pair of addresses (or interfaces) between two communication nodes has failed and picking another pair when this occurs. We call the former "failure detection", and the latter, "locator pair exploration". o Negative feedback from upper-layer protocols. It is conceivable that upper-layer protocols give an indication of a problem to the multihoming layer. For instance, TCP could indicate that there's either congestion or lack of connectivity in the path because it is not getting ACKs. An important observation in multihoming is that failures are relatively infrequent, so an operational pair that worked a few seconds ago is very likely to still be operational. Thus, it makes sense to have a lightweight protocol that confirms existing reachability, and to only invoke heavier exploration mechanism when there is a suspected failure. Out of the set of possible candidate address pairs, nodes SHOULD attempt to test through all of them until an operational pair is found, and retry the process as necessary. However, all nodes MUST perform this process sequentially and with exponential back-off. This sequential process is necessary in order to avoid a "signaling storm" when an outage occurs (particularly for a complete site). However, it also limits the number of addresses that can, in practice, be used for multihoming, considering that transport- and application-layer protocols will fail if the switch to a new address pair takes too long. However, note that in the case of multihoming using BGP, if the failover is fast enough that TCP doesn't go into slow start, the full payload data traffic that flows over the failed path is switched over to the backup path, and if this backup path is of a lower capacity, there will be even more congestion. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [ADD-SEL] Bagnulo, M., "Address selection in multihomed environments", Work in Progress, October 2005. [MULTI6] Huitema, C., "Address selection in multihomed environments", Work in Progress, October 2004. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. This document attempts to summarize the thoughts and unpublished contributions of many people, including MULTI6 WG design team members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis Lindqvist, Margaret Wasserman, and Jukka Ylitalo; MOBIKE WG contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer Dawkins, and James Kempf; and HIP WG contributors such as Pekka Nikander. This document is also in debt to work done in the context of SCTP [RFC4960] and the Host Identity Protocol (HIP) multihoming and mobility extension [RFC5206]. http://www.ietf.org/rfc/rfc5535.txt 5535 Hash-Based Addresses (HBA). M. Bagnulo. June 2009. (Format: TXT=3D63994 bytes) (Status: PROPOSED STANDARD) This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. This mechanism employs either Cryptographically Generated Addresses (CGAs) or a new variant of the same theme that uses the same format in the addresses. The main idea in the new variant is that information about the multiple prefixes is included within the addresses themselves. This is achieved by generating the interface identifiers of the addresses of a host as 1. Introduction ....................................................3 2. Terminology .....................................................4 3. Overview ........................................................4 3.1. Threat Model ...............................................4 3.2. Overview ...................................................4 3.3. Motivations for the HBA Design .............................5 4. Cryptographic Generated Addresses (CGAs) Compatibility Considerations ..................................................6 5. Multi-Prefix Extension for CGA ..................................8 6. HBA-Set Generation ..............................................9 7. HBA Verification ...............................................11 7.1. Verification That a Particular HBA Address Corresponds to a Given CGA Parameter Data Structure .......11 7.2. Verification That a Particular HBA Address Belongs to the HBA Set Associated with a Given CGA Parameter Data Structure .................................................11 8. Example of HBA Application in a Multihoming Scenario ...........13 8.1. Dynamic Address Set Support ...............................16 9. DNS Considerations .............................................17 10. IANA Considerations ...........................................18 11. Security Considerations .......................................18 11.1. Security Considerations When Using HBAs in the Shim6 Protocol ...........................................20 11.2. Privacy Considerations ...................................22 11.3. SHA-1 Dependency Considerations ..........................22 11.4. DoS Attack Considerations ................................22 12. Contributors ..................................................23 13. Acknowledgments ...............................................23 14. References ....................................................24 14.1. Normative References .....................................24 14.2. Informative References ...................................24 In order to preserve inter-domain routing system scalability, IPv6 sites obtain addresses from their Internet Service Providers (ISPs). Such an addressing strategy significantly reduces the amount of routes in the global routing tables, since each ISP only announces routes to its own address blocks, rather than announcing one route per customer site. However, this addressing scheme implies that multihomed sites will obtain multiple prefixes, one per ISP. Moreover, since each ISP only announces its own address block, a multihomed site will be reachable through a given ISP if the ISP prefix is contained in the destination address of the packets. This means that, if an established communication needs to be routed through different ISPs during its lifetime, addresses with different prefixes will have to be used. Changing the address used to carry packets of an established communication exposes the communication to numerous attacks, as described in [11], so security mechanisms are required to provide the required protection to the involved parties. This memo describes a tool that can be used to provide protection against some of the potential attacks, in particular against future/ premeditated attacks (aka time shifting attacks in [12]). This memo describes a mechanism to provide a secure binding between the multiple addresses with different prefixes available to a host within a multihomed site. It should be noted that, as opposed to the mobility case where the addresses that will be used by the mobile node are not known a priori, the multiple addresses available to a host within the multihomed site are pre-defined and known in advance in most of the cases. The mechanism proposed in this memo employs either Cryptographically Generated Addresses (CGAs) [2] or a new variant of the same theme that uses the same format in the addresses. The new variant, Hash-Based Address (HBA), takes advantage of the address set stability. In either case, a secure binding between the addresses of a node in a multihomed site can be provided. CGAs employ public key cryptography and can deal with changing address sets. HBAs employ only symmetric key cryptography, and have smaller computational requirements. The threat analysis for the multihoming problem is described in [11]. This analysis basically identifies attacks based on redirection of packets by a malicious attacker towards addresses that do not belong to the multihomed node. There are essentially two types of redirection attacks: communication hijacking and flooding attacks. Communication hijacking attacks are about an attacker stealing on- going and/or future communications from a victim. Flooding attacks are about redirecting the traffic generated by a legitimate source towards a third party, flooding it. The HBA solution provides full protection against the communication hijacking attacks. The Shim6 protocol [9] protects against flooding attacks. Residual threats are described in the "Security Considerations" section. The basic goal of the HBA mechanism is to securely bind together multiple IPv6 addresses that belong to the same multihomed host. This allows rerouting of traffic without worrying that the communication is being redirected to an attacker. The technique that is used is to include a hash of the permitted prefixes in the low-order bits of the IPv6 address. First of all, the goal of HBA is to provide a secure binding between the IPv6 address used as an identifier by the upper-layer protocols and the alternative locators available in the multihomed node so that redirection attacks are prevented. Fourth, performance considerations as described in [17] motivated the usage of a hash-based approach as opposed to a public-key-based approach based on pure Cryptographic Generated Addresses (CGA), in order to avoid imposing the performance of public key operations for every communication in multihomed environments. The HBA approach presented in this document presents a cheaper alternative that is attractive to many common usage cases. Note that the HBA approach and the CGA approaches are not mutually exclusive and that it is possible to generate addresses that are both valid CGA and HBA addresses providing the benefits of both approaches if needed. As described in the previous section, the HBA technique uses the interface identifier part of the IPv6 address to encode information about the multiple prefixes available to a multihomed host. However, the interface identifier is also used to carry cryptographic information when Cryptographic Generated Addresses (CGAs) [2] are used. Therefore, conflicting usages of the interface identifier bits may result if this is not taken into account during the HBA design. There are at least two valid reasons to provide CGA-HBA compatibility: First, the current Secure Neighbor Discovery (SeND) specification [3] uses the CGAs defined in [2] to prove address ownership. If HBAs are not compatible with CGAs, then nodes using HBAs for multihoming wouldn't be able to do Secure Neighbor Discovery using the same addresses (at least the parts of SeND that require CGAs). This would imply that nodes would have to choose between security (from SeND) and fault tolerance (from IPv6 multihoming support provided by the Shim6 protocol [9]). In addition to SeND, there are other protocols that are considered to benefit from the advantages offered by the CGA scheme, such as mobility support protocols [13]. Those protocols could not be used with HBAs if HBAs are not compatible with CGAs. Second, CGAs provide additional features that cannot be achieved using only HBAs. In particular, because of its own nature, the HBA technique only supports a predetermined prefix set that is known at the time of the generation of the HBA set. No additions of new prefixes to this original set are supported after the HBA set generation. In most of the cases relevant for site multihoming, this is not a problem because the prefix set available to a multihomed set is not very dynamic. New prefixes may be added in a multihomed site when a new ISP is available, but the timing of those events are rarely in the same time scale as the lifetime of established communications. It is then enough for many situations that the new prefix is not available for established communications and that only new communications benefit from it. However, in the case that such functionality is required, it is possible to use CGAs to provide it. This approach clearly requires that HBA and CGA approaches be compatible. If this is the case, it then would be possible to create HBA/CGA addresses that support CGA and HBA functionality simultaneously. The inputs to the HBA/CGA generation process will be both a prefix set and a public key. In this way, a node that has established a communication using one address of the CGA/HBA set can tell its peer to use the HBA verification when one of the addresses - CGA-only addresses: These are addresses generated as specified in [2] without including the Multi-Prefix extension. They are bound to a public key and to a single prefix (contained in the basic CGA Parameter Data Structure). These addresses can be used for SeND [3]; if used for multihoming, their application will have to be based on the public key usage. - HBA-only addresses: These addresses are bound to a prefix set but they are not bound to a public key. Because HBAs are compatible with CGA, the CGA Parameter Data Structure will be used for their generation, but a random nonce will be included in the Public Key field instead of a public key. These addresses can be used for HBA-based multihoming protocols, but they cannot be used for SeND. For multihoming applications, it is also relevant that the receiver of the HBA information verifies if a given HBA address belongs to a certain HBA set. An HBA set is identified by a CGA Parameter Data structure that contains a Multi-Prefix extension. So, the receiver needs to verify if a given HBA belongs to the HBA set defined by a CGA Parameter Data Structure. It should be noted that the receiver 8. Example of HBA Application in a Multihoming Scenario In this section, we will describe a possible application of the HBA technique to IPv6 multihoming. We will consider the following scenario: a multihomed site obtains Internet connectivity through two providers: ISPA and ISPB. Each provider has delegated a prefix to the multihomed site (PrefA::/nA and PrefB::/nb, respectively). In order to benefit from multihoming, the hosts within the multihomed site will configure multiple IP addresses, one per available prefix. The resulting configuration is depicted in the next figure. +-------+ | Host2 | |IPHost2| +-------+ | | (Internet) / \ / \ +------+ +------+ | ISPA | | ISPB | | | | | +------+ +------+ | | \ / \ / +---------------------+ | multihomed site | | PA::/nA | | PB::/nB +------+ | | |Host1 | | | +------+ | +---------------------+ Host2 is not located in a multihomed site, so there is no need for it to create HBAs (it must be able to verify them though, in order to support the Shim6 protocol, as we will describe next). Host1 is located in the multihomed site, so it will generate its addresses as HBAs. In order to do that, it needs to execute the HBA-set generation process as detailed in Section 6 of this memo. The inputs of the HBA-set generation process will be: a prefix vector containing the two prefixes available in its link, i.e., PA:LA::/64 and PB:LB::/64, a Sec parameter value, and optionally a public key. In this case, we will assume that a public key is provided so that we can also illustrate how a renumbering event can be supported when HBA/CGA addresses are used (see the sub-section referring to dynamic address set support). So, after executing the HBA-set generation process, Host1 will have: an HBA-set consisting in two addresses, i.e., PA:LA:iidA and PB:LB:iidB with their respective CGA Parameter Data Structures, i.e., CGA_PDS_A and CGA_PDS_B. Note that iidA and iidB are different but both contain information about the prefix set available in the multihomed site. We will next consider a communication between Host1 and Host2. Assume that both ISPs of the multihomed site are working properly, so any of the available addresses in Host1 can be used for the communication. Suppose then that the communication is established using PA:LA:iidA and IPHost2 for Host1 and Host2, respectively. So far, no special Shim6 support has been required, and PA:LA:iidA is used as any other global IP address. Suppose that at a certain moment, one of the hosts involved in the communication decides that multihoming support is required in this communication (this basically means that one of the hosts involved in the communication desires enhanced fault-tolerance capabilities for this communication, so that if an outage occurs, the communication can be re-homed to an alternative provider). HBAs provide protection against time shifting attacks [11], [12]. In the multihoming context, an attacker would perform a time shifted attack in the following way: an attacker placed along the path of the communication will modify the packets to include an additional address as a valid address for the communication. Then the attacker would leave the on-path location, but the effects of the attack would remain (i.e., the address would still be considered as a valid address for that communication). Next we will present how HBAs can be used to prevent such attacks. [9] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. [11] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. [17] Bagnulo, M., Garcia-Martinez, A., and A. Azcorra, "Efficient Security for IPv6 Multihoming", ACM Computer Communications Review Vol 35 n 2, April 2005. http://www.ietf.org/rfc/rfc5555.txt 5555 Mobile IPv6 Support for Dual Stack Hosts and Routers. H. Soliman, Ed.. June 2009. (Format: TXT=3D92387 bytes) (Status: PROPOSED = STANDARD) [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc5558.txt 5558 Virtual Enterprise Traversal (VET). F. Templin, Ed.. February 2010. (Format: TXT=3D88504 bytes) (Status: INFORMATIONAL) 1. Introduction ....................................................4 2. Terminology .....................................................6 3. Enterprise Characteristics .....................................10 4. Autoconfiguration ..............................................11 4.1. Enterprise Router (ER) Autoconfiguration ..................12 4.2. Enterprise Border Router (EBR) Autoconfiguration ..........13 4.2.1. VET Interface Autoconfiguration ....................13 4.2.1.1. Interface Initialization ..................14 4.2.1.2. Enterprise Border Gateway Discovery and Enterprise Identification ...14 4.2.1.3. EID Configuration .........................15 4.2.2. Provider-Aggregated (PA) EID Prefix Autoconfiguration ..................................15 4.2.3. Provider-Independent (PI) EID Prefix Autoconfiguration ..................................16 4.3. Enterprise Border Gateway (EBG) Autoconfiguration .........17 4.4. VET Host Autoconfiguration ................................17 5. Internetworking Operation ......................................18 5.1. Routing Protocol Participation ............................18 5.2. RLOC-Based Communications .................................18 5.3. EID-Based Communications ..................................18 5.4. IPv6 Router Discovery and Prefix Registration .............18 5.4.1. IPv6 Router and Prefix Discovery ...................18 5.4.2. IPv6 PA Prefix Registration ........................19 5.4.3. IPv6 PI Prefix Registration ........................20 5.4.4. IPv6 Next-Hop EBR Discovery ........................21 5.5. IPv4 Router Discovery and Prefix Registration .............23 5.6. VET Encapsulation .........................................24 5.7. SEAL Encapsulation ........................................24 5.8. Generating Errors .........................................25 5.9. Processing Errors .........................................25 5.10. Mobility and Multihoming Considerations ..................26 5.11. Multicast ................................................27 5.12. Service Discovery ........................................28 5.13. Enterprise Partitioning ..................................29 5.14. EBG Prefix State Recovery ................................29 6. Security Considerations ........................................30 7. Related Work ...................................................30 8. Acknowledgements ...............................................31 9. Contributors ...................................................31 10. References ....................................................31 10.1. Normative References .....................................31 10.2. Informative References ...................................33 Appendix A. Duplicate Address Detection (DAD) Considerations .... 36 Enterprise networks must have a means for supporting both Provider- Independent (PI) and Provider-Aggregated (PA) IP prefixes. This is especially true for enterprise scenarios that involve mobility and multihoming. Also in scope are ingress filtering for multihomed sites, adaptation based on authenticated ICMP feedback from on-path routers, effective tunnel path MTU mitigations, and routing scaling suppression as required in many enterprise network scenarios. In many enterprise scenarios, the use of EID-based communications (i.e., instead of RLOC-based communications) may be necessary and/or beneficial to support address scaling, NAT avoidance, security domain separation, site multihoming, traffic engineering, etc. the prefix was already installed in the distributed database, the EBG instead adds the outer RLOC source address (e.g., in an additional DNS A record) to the preexisting publication to support PI prefixes that are multihomed. For enterprises that use SEND, this latter provision requires all EBRs of a multihomed site that advertise the same PI prefixes in RAs to use the same CGA and the same SEND credentials. 5.10. Mobility and Multihoming Considerations EBRs may register their PI prefixes with multiple EBGs for multihoming purposes. EBRs should only forward packets via EBGs with which it has registered its PI prefixes, since other EBGs may drop the packets and return ICMPv6 "Destination Unreachable; Source address failed ingress/egress policy" messages. The EBGs of a multihomed enterprise should participate in a private inner IP routing protocol instance between themselves (possibly over an alternate topology) to accommodate enterprise partitions/merges as well as intra-enterprise mobility events. These peer EBGs should accept packets from one another without respect to the destination (i.e., ingress filtering is based on the peering relationship rather than a prefix-specific ingress filter entry). [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5572.txt 5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP). M. Blanchet, F. Parent. February 2010. (Format: TXT=3D60017 bytes) (Status: EXPERIMENTAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5626.txt 5626 Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). C. Jennings, Ed., R. Mahy, Ed., F. Audet, Ed.. October 2009. (Format: TXT=3D116344 bytes) (Updates RFC3261, = RFC3327) (Status: PROPOSED STANDARD) Another motivation for maintaining multiple flows between the UA and its registrar is related to multihomed UAs. Such UAs can benefit from multiple connections from different interfaces to protect against the failure of an individual access link. http://www.ietf.org/rfc/rfc5635.txt 5635 Remote Triggered Black Hole Filtering with Unicast Reverse Path Forwarding (uRPF). W. Kumari, D. McPherson. August 2009. (Format: TXT=3D30232 bytes) (Status: INFORMATIONAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5638.txt 5638 Simple SIP Usage Scenario for Applications in the Endpoints. H. Sinnreich, Ed., A. Johnston, E. Shim, K. Singh. September 2009. (Format: TXT=3D45946 bytes) (Status: INFORMATIONAL) One approach for NAT traversal that is generic and applicable for all application protocols is to deploy the Host Identity Protocol (HIP) and solve NAT traversal only once, at the HIP level. HIP has many other useful features (such as support for the IPv6 transition in endpoints, mobility, and multihoming) that are beyond the scope of this paper. "Basic HIP Extensions for Traversal of Network Address Translators" [23] provides an extensive coverage of the use of HIP for NAT traversal. http://www.ietf.org/rfc/rfc5648.txt 5648 Multiple Care-of Addresses Registration. R. Wakikawa, Ed., V. Devarapalli, G. Tsirtsis, T. Ernst, K. Nagami. October 2009. = (Format: TXT=3D90112 bytes) (Updated by RFC6089) (Status: PROPOSED STANDARD) The binding management mechanisms are the same for a mobile host that uses Mobile IPv6 and for a mobile router that is using the NEMO Basic Support protocol [RFC3963]. Therefore, the extensions described in this document can also be used to support a mobile router with multiple care-of addresses. [RFC4980] contains an analysis of NEMO multihoming. [RFC4980] Ng, C., Ernst, T., Paik, E., and M. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. [MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008. http://www.ietf.org/rfc/rfc5720.txt 5720 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER). F. Templin. February 2010. (Format: TXT=3D65956 bytes) (Status: INFORMATIONAL) RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a Small Office, Home Office (SOHO) network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and provides a comprehensive framework for IPv6/IPv4 coexistence. 1. Introduction ....................................................3 2. Terminology .....................................................4 3. The RANGER Architecture .........................................7 3.1. Routing and Addressing .....................................7 3.2. The Enterprise-within-Enterprise Framework .................9 3.3. Virtual Enterprise Traversal (VET) ........................12 3.3.1. RANGER Organizational Principles ...................12 3.3.2. RANGER End-to-End Addressing Example ...............14 3.3.3. Dynamic Routing and On-Demand Mapping ..............14 3.3.4. Support for Legacy RLOC-Based Services .............16 3.4. Subnetwork Encapsulation and Adaptation Layer (SEAL) ......18 3.5. Mobility Management .......................................18 3.6. Multihoming ...............................................20 3.7. Implications for the Internet .............................20 4. Related Initiatives ............................................21 5. Security Considerations ........................................22 6. Acknowledgements ...............................................23 7. References .....................................................23 7.1. Normative References ......................................23 7.2. Informative References ....................................24 RANGER is an architectural framework for scalable routing and addressing in networks with global enterprise recursion. The term "enterprise network" within this context extends to a wide variety of use cases and deployment scenarios, where an "enterprise" can be as small as a SOHO network, as dynamic as a Mobile Ad Hoc Network, as complex as a multi-organizational corporation, or as large as the global Internet itself. Such networks will require an architected solution for the coordination of routing and addressing plans with accommodations for scalability, provider-independence, mobility, multihoming, and security. These considerations are particularly true for existing deployments, but the same principles apply even for clean-slate approaches. The RANGER architecture addresses these requirements and also provides a comprehensive framework for IPv6/ IPv4 coexistence [COEXIST]. o site mobility and multihoming VET Virtual Enterprise Traversal (VET) [VET]; functional specifications and operational practices for automatic tunneling of both unicast and multicast IP packets with provisions for address/prefix autoconfiguration, provider-independent addressing, mobility, multihoming, and security. VET is descended from both 6over4 and ISATAP and is also known as "ISATAP version 2 (ISATAPv2)". Mobile enterprises with PI prefixes that use VET and SEAL can move between parent enterprise attachment points as long as they withdraw the prefixes from the mapping systems of departed enterprises and inject them into the mapping systems of new enterprises. When moving between the lower recursive tiers of a common parent enterprise, such a localized event mobility may result in no changes to the parent enterprise's mapping system. Hence, the organizational structure of a carefully arranged enterprise-within-enterprise framework may be able to dampen mobility-related churn. For enterprises that require in-the-network confidentiality, IKEv2 Mobility and Multihoming (MOBIKE) [RFC4555] may also be useful within this context. 3.6. Multihoming As with mobility management, multihoming use cases must be considered along multiple vectors. Within an enterprise, EBRs can discover multiple EBGs and use them in a fault-tolerant and load-balancing fashion as long as they register their PI prefixes with each such EBG, as described in Section 3.3.1. These registrations are created through the transmission of Router Advertisement messages that percolate up through the recursive enterprise-within-enterprise hierarchy. While RANGER shares many properties with these earlier works, it uniquely provides a top-to-bottom articulation of how the various pieces fit together within a recursively nested "enterprise-within- enterprise" (or "network-of-networks") framework. In this way, it bears striking resemblance to the network-of-networks model envisioned by CATENET. RANGER further provides a detailed consideration of challenging issues such as autoconfiguration, provider-independent addressing, border router discovery, tunnel MTU, multihoming, etc. that many other approaches have either overlooked or left for future work. A detailed analysis of RANGER applicability in various use case scenarios is provided in "RANGER Scenarios (RANGERS)" [RUSSERT]. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc5723.txt 5723 Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption. Y. Sheffer, H. Tschofenig. January 2010. (Format: TXT=3D59201 bytes) (Status: PROPOSED STANDARD) [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc5739.txt 5739 IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2). P. Eronen, J. Laganier, C. Madson. February 2010. (Format: TXT=3D67691 bytes) (Status: EXPERIMENTAL) Multiple prefixes are useful for site renumbering, host-based site multihoming [SHIM6], and unique local IPv6 addresses [RFC4193]. In all of these cases, the gateway has better information on how many different addresses (from different prefixes) the client should be assigned. [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [SHIM6] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. http://www.ietf.org/rfc/rfc5757.txt 5757 Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey. T. Schmidt, M. Waehlisch, G. Fairhurst. February 2010. (Format: TXT=3D92632 bytes) (Status: INFORMATIONAL) The host group model extends the capability of the network-layer unicast service. In common with the architecture of fixed networks, multicast mobility management should transparently utilize or smoothly extend the unicast functions of MIPv6 [5], its security extensions [6][18], its expediting schemes FMIPv6 [19] and Hierarchical Mobile IPv6 Environment (HMIPv6) [20], its context transfer protocols [21], its multihoming capabilities [22][23], emerging protocols like PMIPv6 [62], or future developments. From the perspective of an integrated mobility architecture, it is desirable to avoid multicast-specific as well as unicast-restricted solutions, whenever general approaches can be derived that can jointly support unicast and multicast. Moreover, in many wireless regimes, it is also desirable to minimize multicast-related signaling to preserve the limited resources of battery-powered mobile devices and the constrained transmission capacities of the networks. This may lead to a desire to restrict MLD queries towards the MN. Multihomed MNs may ensure smooth handoffs by using a "make-before-break" approach, which requires a per-interface subscription, facilitated by an MLD JOIN operating on a pre-selected IPv6 interface. [22] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, May 2008. http://www.ietf.org/rfc/rfc5770.txt 5770 Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators. M. Komu, T. Henderson, H. Tschofenig, = J. Melen, A. Keranen, Ed.. April 2010. (Format: TXT=3D79767 bytes) (Status: EXPERIMENTAL) If the Initiator receives a NAT traversal mode parameter in R1 without UDP encapsulation, the Initiator MAY ignore this parameter and send an I2 without UDP encapsulation and without any selected NAT traversal mode. When the Responder receives the I2 without UDP encapsulation and without NAT traversal mode, it will assume that no NAT traversal mechanism is needed. The packet processing will be done as described in [RFC5201]. The Initiator MAY store the NAT traversal modes for future use, e.g., in case of a mobility or multihoming event that causes NAT traversal to be used during the lifetime of the HIP association. It is also possible that end-users may not want to reveal all locators to each other. For example, tracking the physical location of a multihoming end-host may become easier if it reveals all locators to its peer during a base exchange. Also, revealing host addresses exposes information about the local topology that may not be allowed in all corporate environments. For these two reasons, an end-host may exclude certain host addresses from its LOCATOR parameter. However, such behavior creates non-optimal paths when the hosts are located behind the same NAT. Especially, this could be problematic with a legacy NAT that does not support routing from the private address realm back to itself through the outer address of the NAT. This scenario is referred to as the hairpin problem [RFC5128]. With such a legacy NAT, the only option left would be to use a relayed transport address from a TURN server. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. http://www.ietf.org/rfc/rfc5773.txt 5773 Analysis of Inter-Domain Routing Requirements and History. E. Davies, A. Doria. February 2010. (Format: TXT=3D127384 bytes) = (Status: HISTORIC) [Berkowitz01] Berkowitz, H. and D. Krioukov, "To Be Multihomed: Requirements and Definitions", Work in Progress, July 2001. [RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. http://www.ietf.org/rfc/rfc5783.txt 5783 Congestion Control in the RFC Series. M. Welzl, W. Eddy. February 2010. (Format: TXT=3D68231 bytes) (Status: INFORMATIONAL) SCTP congestion control is very similar to TCP with Selective Acknowledgements, but there are some differences, as described in Section 7.1 of [RFC4960]. The major difference lies in the fact that SCTP supports multihoming, whereas TCP does not. Thus, SCTP http://www.ietf.org/rfc/rfc5837.txt 5837 Extending ICMP for Interface and Next-Hop Identification. A. Atlas, Ed., R. Bonica, Ed., C. Pignataro, Ed., N. Shen, JR. Rivers. April 2010. (Format: TXT=3D38109 bytes) (Status: PROPOSED STANDARD) Similarly, [RFC1122] provides guidance for source address selection for multihomed IPv4 hosts. These recommendations, like those stated above, do not always cause the source address of an ICMPv4 message to identify the incoming interface. http://www.ietf.org/rfc/rfc5879.txt 5879 Heuristics for Detecting ESP-NULL Packets. T. Kivinen, D. McDonald. May 2010. (Format: TXT=3D72917 bytes) (Status: = INFORMATIONAL) The flow lookup code needs to detect UDP packets to or from port 4500 in addition to the ESP packets, and perform similar processing to them after skipping the UDP header. Port-translation by NAT often rewrites what was originally 4500 into a different value, which means each unique port pair constitutes a separate IPsec flow. That is, UDP-encapsulated IPsec flows are identified by the source and destination IP, source and destination port number, and SPI number. As devices might be using IKEv2 Mobility and Multihoming (MOBIKE) ([RFC4555]), that also means that the flow cache should be shared between the UDP encapsulated IPsec flows and non-encapsulated IPsec flows. As previously mentioned, differentiating between garbage and actual policy failures will help in proper detection immensely. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc5887.txt 5887 Renumbering Still Needs Work. B. Carpenter, R. Atkinson, H. Flinck. May 2010. (Format: TXT=3D87131 bytes) (Status: = INFORMATIONAL) There is work in progress that, if successful, would eliminate some of the motivations for renumbering. In particular, some types of solutions to the problem of scalable routing for multihomed sites would likely eliminate both multihoming and switching to another ISP as reasons for site renumbering. Also, it should be noted that on an isolated LAN, neither RA nor DHCPv6 responses will be received, and the host will remain with only its self-assigned link-local address. One could also have a situation where a multihomed network uses SLAAC for one address prefix and DHCPv6 for another, which would clearly create a risk of inconsistent host behaviour and operational confusion. In contrast, Stream Control Transmission Protocol (SCTP) already supports dynamic multihoming of session endpoints, so SCTP sessions ought not be adversely impacted by renumbering the SCTP session endpoints [RFC4960] [RFC5061]. In IPv6, if a site wanted to be multihomed using multiple provider- aggregated (PA) routing prefixes with one prefix per upstream provider, then the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). In this case, their Router Advertisement messages could be updated dynamically to only advertise currently valid routing prefixes to hosts. This would be significantly more complicated if the various provider prefixes were of different lengths or if the site had non-uniform subnet prefix lengths. When a renumbering event takes place, entries in the state table of any Network Address Translator that happen to contain the affected addresses will become invalid and will eventually time out. Since TCP and UDP sessions are unlikely to survive renumbering anyway, the hosts involved will not be additionally affected. The situation is more complex for multihomed SCTP [SCTPNAT], depending on whether a single or multiple NATs are involved. It should be noted that the management and administration issues (i.e., tracking down, recording, and updating all instances where addresses are stored rather than looked up dynamically) form the dominant concern of managers considering the renumbering problem. This has led many sites to continue the pre-CIDR (Classless Inter- Domain Routing) approach of using a provider-independent (PI) prefix. Some sites, including very large corporate networks, combine PI addressing with NAT. Others have adopted private addressing and NAT as a matter of choice rather than obligation. This range of techniques allows for addressing plans that are independent of the ISP(s) in use, and allows a straightforward approach to multihoming. The direct cost of renumbering is perceived to exceed the indirect costs of these alternatives. Additionally, there is a risk element SHIM6, proposed as a host-based multihoming mechanism for IPv6, has the property of dynamically switching the addresses used for forwarding the actual packet stream while presenting a constant address as the upper-layer identifier for the transport layer [RFC5533]. At least in principle, this property could be used during renumbering to alleviate the problem described in Section 5.1.2. SHIM6 is an example of a class of solutions with this or a similar property; others are Host Identity Protocol (HIP), IKEv2 Mobility and Multihoming (MOBIKE), Mobile IPv6, SCTP, and proposals for multi-path TCP. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. http://www.ietf.org/rfc/rfc5902.txt 5902 IAB Thoughts on IPv6 Network Address Translation. D. Thaler, L. Zhang, G. Lebovitz. July 2010. (Format: TXT=3D37224 bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. What is the problem? . . . . . . . . . . . . . . . . . . . . . 3 2.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . . . 3 2.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 4 2.3. Homogenous Edge Network Configurations . . . . . . . . . . 4 2.4. Network Obfuscation . . . . . . . . . . . . . . . . . . . 5 2.4.1. Hiding Hosts . . . . . . . . . . . . . . . . . . . . . 5 2.4.2. Topology Hiding . . . . . . . . . . . . . . . . . . . 8 2.4.3. Summary Regarding NAT as a Tool for Network Obfuscation . . . . . . . . . . . . . . . . . . . . . 8 2.5. Simple Security . . . . . . . . . . . . . . . . . . . . . 9 2.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Architectural Considerations of IPv6 NAT . . . . . . . . . . . 9 4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IAB Members at the Time of Approval . . . . . . . . . . . . . 13 7. Informative References . . . . . . . . . . . . . . . . . . . . 14 The discussions on the desire for IPv6 NAT can be summarized as follows. Network address translation is viewed as a solution to achieve a number of desired properties for individual networks: avoiding renumbering, facilitating multihoming, making configurations homogenous, hiding internal network details, and providing simple security. 2.2. Site Multihoming Another important requirement in many networks is site multihoming. A multihomed site essentially requires that its IP prefixes be present in the global routing table to achieve the desired reliability in its Internet connectivity as well as load balancing. In today's practice, multihomed sites with PI addresses announce their PI prefixes to the global routing system; multihomed sites with provider-allocated (PA) addresses also announce the PA prefix they obtained from one service provider to the global routing system through another service provider, effectively disabling provider- based prefix aggregation. This practice makes the global routing table scale linearly with the number of multihomed user networks. This issue was identified in [RFC4864], Section 6.4. Unfortunately, no solution except NAT has been deployed today that can insulate the global routing system from the growing number of multihomed sites, where a multihomed site simply assigns multiple IPv4 addresses (one from each of its service providers) to its exit router, which is an IPv4 NAT box. Using address translation to facilitate multihoming support has one unique advantage: there is no impact on the routing system scalability, as the NAT box simply takes one address from each service provider, and the multihomed site does not inject its own routes into the system. Intuitively, it also seems straightforward to roll the same solution into multihoming support in the IPv6 deployment. However, one should keep in mind that this approach brings all the drawbacks of putting a site behind a NAT box, including the loss of reachability to the servers behind the NAT box. It is also important to point out that a multihomed site announcing its own prefix(es) achieves two important benefits that NAT-based multihoming support does not provide. First, end-to-end communications can be preserved in face of connectivity failures of individual service providers, as long as the site remains connected through at least one operational service provider. Second, announcing one's prefixes also gives a multihomed site the ability to perform traffic engineering and load balancing. At present, the primary benefits one may receive from deploying NAT appear to be avoiding renumbering, facilitating multihoming without impacting routing scalability, and making edge consumer network configurations homogenous. One may argue that the answers to the above questions depend on whether we can find adequate solutions to the renumbering, site multihoming, and edge network configuration problems, and whether the solutions provide transparency or not. If transparency is not provided, making NAT a permanent building block in the Internet would represent a fundamental architectural change. =46rom an end-to-end perspective, the solution space for renumbering and multihoming can be broadly divided into three classes: While we do not consider IPv6 NATs to be desirable, we understand that some deployment of them is likely unless workable solutions to avoiding renumbering, facilitating multihoming without adversely impacting routing scalability, and homogeneity are generally recognized as useful and appropriate. http://www.ietf.org/rfc/rfc5920.txt 5920 Security Framework for MPLS and GMPLS Networks. L. Fang, Ed.. July 2010. (Format: TXT=3D152830 bytes) (Status: INFORMATIONAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc5944.txt 5944 IP Mobility Support for IPv4, Revised. C. Perkins, Ed.. November 2010. (Format: TXT=3D239935 bytes) (Obsoletes RFC3344) (Status: PROPOSED STANDARD) For multihomed home agents, the source address in the outer IP header of the encapsulated datagram MUST be the address sent to the mobile node in the Home Agent field of the Registration Reply. That is, the home agent cannot use the address of some other network interface as the source address. http://www.ietf.org/rfc/rfc5949.txt 5949 Fast Handovers for Proxy Mobile IPv6. H. Yokota, K. Chowdhury, R. Koodli, B. Patil, F. Xia. September 2010. (Format: TXT=3D72722 = bytes) (Status: PROPOSED STANDARD) Assuming that there is a valid MN Link-layer Identifier (MN LL-ID), the following solution can be considered. When the NMAG receives the MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck message, the NMAG compares it with the new MN LL-ID that is obtained from the mobile node in the N-AN. If these two MN LL-IDs are the same, the handoff type falls into type 3 (defined above) and the Handoff Indicator value is set to 3. If these two MN LL-IDs are different, the handoff is likely to be type 2 (defined above) since the HI/HAck message exchange implies that this is a handoff rather than a multihoming, and therefore the Handoff Indicator value can be set to 2. If there is no HI/HAck exchange performed prior to the network attachment of the mobile node in the N-AN, the NMAG may infer that this is a multi-homing case and set the Handoff Indicator value to 1. In the case of re-registration, the MAG, to which the mobile node is attached, can determine if the handoff state is not changed, so the MAG can set the HI value to 5 without any additional information. If no handoff type can be assumed or if there is no valid MN LL-ID available, the NMAG may set the value to 4. http://www.ietf.org/rfc/rfc5971.txt 5971 GIST: General Internet Signalling Transport. H. Schulzrinne, R. Hancock. October 2010. (Format: TXT=3D381127 bytes) (Status: EXPERIMENTAL) o Messages for more than one flow may use the same SID, for example, because one flow is replacing another in a mobility or multihoming scenario. The interface-address must be routable, i.e., it MUST be usable as a destination IP address for packets to be sent back to the node generating the signalling message, whether in D-mode or C-mode. If this object is carried in a message with the source addressing mode flag S=3D1, the interface-address MUST match the source address used = in the IP encapsulation, to assist in legacy NAT detection (Section 7.2.1). If this object is carried in a Query or Confirm, the interface-address MUST specifically be set to an address bound to an interface associated with the MRI, to allow its use in route change handling as discussed in Section 7.1. A suitable choice is the interface that is carrying the outbound flow. A node may have several choices for which of its addresses to use as the interface-address. For example, there may be a choice of IP versions, or addresses of limited scope (e.g., link-local), or addresses bound to different interfaces in the case of a router or multihomed host. However, some of these interface addresses may not be usable by the peer. A node MUST follow a policy of using a global address of the same IP version as in the MRI, unless it can establish that an alternative address would also be usable. http://www.ietf.org/rfc/rfc5973.txt 5973 NAT/Firewall NSIS Signaling Layer Protocol (NSLP). M. Stiemerling, H. Tschofenig, C. Aoun, E. Davies. October 2010. (Format: TXT=3D219962 bytes) (Status: EXPERIMENTAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Scope and Background . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology and Abbreviations . . . . . . . . . . . . . . 8 1.3. Notes on the Experimental Status . . . . . . . . . . . . . 10 1.4. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10 1.5. General Scenario for NATFW Traversal . . . . . . . . . . . 11 2. Network Deployment Scenarios Using the NATFW NSLP . . . . . . 13 2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13 2.2. NAT with Two Private Networks . . . . . . . . . . . . . . 14 2.3. NAT with Private Network on Sender Side . . . . . . . . . 15 2.4. NAT with Private Network on Receiver Side Scenario . . . . 15 2.5. Both End Hosts behind Twice-NATs . . . . . . . . . . . . . 16 2.6. Both End Hosts behind Same NAT . . . . . . . . . . . . . . 17 2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18 2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 18 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 19 3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 20 3.2.1. Signaling for Outbound Traffic . . . . . . . . . . . . 20 3.2.2. Signaling for Inbound Traffic . . . . . . . . . . . . 22 3.2.3. Signaling for Proxy Mode . . . . . . . . . . . . . . . 23 3.2.4. Blocking Traffic . . . . . . . . . . . . . . . . . . . 24 3.2.5. State and Error Maintenance . . . . . . . . . . . . . 24 3.2.6. Message Types . . . . . . . . . . . . . . . . . . . . 25 3.2.7. Classification of RESPONSE Messages . . . . . . . . . 25 3.2.8. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26 3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 27 3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27 3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 31 3.6. Authentication, Authorization, and Policy Decisions . . . 32 3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32 3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32 3.7.2. Reserving External Addresses . . . . . . . . . . . . . 35 3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 43 3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 45 3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 46 3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 48 3.8. Demultiplexing at NATs . . . . . . . . . . . . . . . . . . 53 3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 54 3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 55 4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 55 4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 56 4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 57 4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 58 4.2.2. External Address Object . . . . . . . . . . . . . . . 58 4.2.3. External Binding Address Object . . . . . . . . . . . 59 o Multihomed NAT 2.7. Multihomed Network with NAT The previous sub-sections sketched network topologies where several NATs and/or firewalls are ordered sequentially on the path. This section describes a multihomed scenario with two NATs placed on alternative paths to the public network. Figure 8: Multihomed Network with Two NATs 2.8. Multihomed Network with Firewall This section describes a multihomed scenario with two firewalls placed on alternative paths to the public network (Figure 9). The routing in the private and public networks decides which firewall is being taken for data flows. Depending on the data flow's direction, either outbound or inbound, a different firewall could be traversed. This is a challenge for the EXTERNAL message of the NATFW NSLP where the NSIS responder is located behind these firewalls within the private network. The EXTERNAL message is used to block a particular data flow on an inbound firewall. NSIS must route the EXTERNAL message inbound from NR to NI probably without knowing which path the data traffic will take from NI to NR (see also Appendix C). Figure 9: Multihomed Network with Two Firewalls When a data receiver, and thus NR, is located in a network site that is multihomed with several independently firewalled connections to the public Internet (as shown in Figure 36), the specific firewall through which the data traffic will be routed has to be ascertained. NATFW NSLP signaling messages sent from the NI+/NR during the EXTERNAL message exchange towards the NR+ must be routed by the NTLP to the edge-firewall that will be passed by the data traffic as well. The NTLP would need to be aware about the routing within the Internet to determine the path between the DS and DR. Out of this, the NTLP could determine which of the edge-firewalls, either EFW1 or EFW2, must be selected to forward the NATFW NSLP signaling. Signaling to the wrong edge-firewall, as shown in Figure 36, would install the NATFW NSLP policy rules at the wrong device. This causes either a blocked data flow (when the policy rule is 'allow') or an ongoing attack (when the policy rule is 'deny'). Requiring the NTLP to know all about the routing within the Internet is definitely a tough challenge and usually not possible. In a case as described, the NTLP must basically give up and return an error to the NSLP level, indicating that the next hop discovery is not possible. http://www.ietf.org/rfc/rfc5974.txt 5974 NSIS Signaling Layer Protocol (NSLP) for Quality-of-Service Signaling. J. Manner, G. Karagiannis, A. McDonald. October 2010. (Format: TXT=3D233309 bytes) (Status: EXPERIMENTAL) Session Identification (SESSION-ID, SID): This is a cryptographically random and (probabilistically) globally unique identifier of the application-layer session that is associated with a certain flow. Often, there will only be one data flow for a given session, but in mobility/multihoming scenarios, there may be more than one, and they may be differently routed [RFC4080]. http://www.ietf.org/rfc/rfc5980.txt 5980 NSIS Protocol Operation in Mobile Environments. T. Sanda, Ed., X. Fu, S. Jeong, J. Manner, H. Tschofenig. March 2011. (Format: TXT=3D77323 bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation and Terminology . . . . . . . . . . . . 4 3. Challenges with Mobility . . . . . . . . . . . . . . . . . . . 5 4. Basic Operations for Mobility Support . . . . . . . . . . . . 8 4.1. General Functionality . . . . . . . . . . . . . . . . . . 8 4.2. QoS NSLP . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. NATFW NSLP . . . . . . . . . . . . . . . . . . . . . . . . 12 4.4. Localized Signaling in Mobile Scenarios . . . . . . . . . 13 4.4.1. CRN Discovery . . . . . . . . . . . . . . . . . . . . 15 4.4.2. Localized State Update . . . . . . . . . . . . . . . . 15 5. Interaction with Mobile IPv4/v6 . . . . . . . . . . . . . . . 16 5.1. Interaction with Mobile IPv4 . . . . . . . . . . . . . . . 17 5.2. Interaction with Mobile IPv6 . . . . . . . . . . . . . . . 19 5.3. Interaction with Mobile IP Tunneling . . . . . . . . . . . 20 5.3.1. Sender-Initiated Reservation with Mobile IP Tunnel . . 20 5.3.2. Receiver-Initiated Reservation with Mobile IP Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.3. CRN Discovery and State Update with Mobile IP Tunneling . . . . . . . . . . . . . . . . . . . . . . 24 6. Further Studies . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. NSIS Operation in the Multihomed Mobile Environment . . . 25 6.1.1. Selecting the Best Interface(s) or CoA(s) . . . . . . 26 6.1.2. Differentiation of Two Types of CRNs . . . . . . . . . 27 6.2. Interworking with Other Mobility Protocols . . . . . . . . 28 6.3. Intermediate Node Becomes a Dead Peer . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 This document focuses on basic mobility scenarios. Key management related to handovers, multihoming, and interactions between NSIS and other mobility management protocols than Mobile IP are out of scope of this document. Also, practical implementations typically need various APIs across components within a node. API issues, e.g., APIs from GIST to the various mobility and routing schemes, are also out of scope of this work. The generic GIST API towards NSLP is flexible enough to fulfill most mobility-related needs of the NSLP layer. All sections above dealt with basic issues on NSIS mobility support. This section introduces potential issues and possible approaches for complicated scenarios in the mobile environment, i.e., peer failure scenarios, multihomed scenarios, and interworking with other mobility protocols, which may need to be resolved in the future. Topics in this section are out of scope for this document. Detailed operations in this section are just for future reference. 6.1. NSIS Operation in the Multihomed Mobile Environment In multihomed mobile environments, multiple interfaces and addresses (i.e., CoAs and HoAs) are available, so two major issues can be considered. One is how to select or acquire the most appropriate interface(s) and/or address(es) from the end-to-end QoS point of view. The other is, when multiple paths are simultaneously used for load-balancing purposes, how to differentiate and manage two types of CRNs, i.e., the CRN between two ongoing paths (LB-CRN: Load Balancing CRN) and the CRN between the old and new paths caused by the MN's handover (HO-CRN: Handover CRN). This section introduces possible approaches for these issues. Figure 9: Receiver-Initiated Reservation in the Multihomed Environment (a) NSIS Path classification in multihomed environments Figure 10: The Topology for NSIS Signaling in Multihomed Mobile Environments In the interdomain handover, a possible way to mitigate the latency penalty is to use the multihomed MN. It is also possible to allow the NSIS protocols to interact with mobility protocols such as Seamoby protocols (e.g., Candidate Access Router Discovery (CARD) [RFC4066] and the Context Transfer Protocol (CXTP) [RFC4067]) and Fast Mobile IP (FMIP). Another scenario is to use a peering agreement that allows aggregation authorization to be performed for aggregate reservation on an interdomain link without authorizing each individual session. How these approaches can be used in NSIS signaling is for further study. http://www.ietf.org/rfc/rfc5996.txt 5996 Internet Key Exchange Protocol Version 2 (IKEv2). C. Kaufman, P. Hoffman, Y. Nir, P. Eronen. September 2010. (Format: TXT=3D346466 bytes) (Obsoletes RFC4306, RFC4718) (Updated by RFC5998) (Status: PROPOSED STANDARD) o There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). This will be apparent to a host if it receives a packet whose integrity protection validates, but has a different port, address, or both from the one that was associated with the SA in the validated packet. When such a validated packet is found, a host that does not support other methods of recovery such as IKEv2 Mobility and Multihoming (MOBIKE) [MOBIKE], and that is not behind a NAT, SHOULD send all packets (including retransmission packets) to the IP address and port in the validated packet, and SHOULD store this as the new address and port combination for the SA (that is, they SHOULD dynamically update the address). A host behind a NAT SHOULD NOT do this type of dynamic address update if a validated packet has [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. http://www.ietf.org/rfc/rfc6013.txt 6013 TCP Cookie Transactions (TCPCT). W. Simpson. January 2011. (Format: TXT=3D76505 bytes) (Status: EXPERIMENTAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc6036.txt 6036 Emerging Service Provider Scenarios for IPv6 Deployment. B. Carpenter, S. Jiang. October 2010. (Format: TXT=3D45113 bytes) = (Status: INFORMATIONAL) Although the basic IPv6 standards have long been stable, it should be noted that considerable work continues in the IETF, particularly to resolve the issue of highly scalable multihoming support for IPv6 sites, and to resolve the problem of IP layer interworking between IPv6-only and IPv4-only hosts. IPv6/IPv4 interworking at the application layers is handled within the original dual-stack model of IPv6 deployment: either one end of an application session will have dual-stack connectivity, or a dual-stack intermediary such as an HTTP proxy or SMTP server will interface to both IPv4-only and IPv6-only hosts or applications. 80% of the respondents offer both transit and origin-only service; 29% offer IP multicast service; 80% have multihomed customers. Finally, there was a comment that real deployment case studies must be shown to operators along with multihoming and traffic engineering best practices. o Do any customers require multihoming to multiple ISPs? 25 yes, 6 no 5. Do any of your customers require multihoming to multiple ISPs? http://www.ietf.org/rfc/rfc6071.txt 6071 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap. S. Frankel, S. Krishnan. February 2011. (Format: = TXT=3D148655 bytes) (Obsoletes RFC2411) (Status: INFORMATIONAL) The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two additional capabilities for IPsec VPN users: 1) moving from one address to another without re-establishing existing SAs and 2) using multiple interfaces simultaneously. These solutions are limited to IPsec VPNs; they are not intended to provide more general mobility or multihoming capabilities. 4.2.4.1. RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, June 2006) 4.2.4.2. RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol (I, August 2006) 4.2.4.3. RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 2008) 8.3.3. RFC 5206, End-Host Mobility and Multihoming with the Host Identity (E, April 2008) [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, August 2006. [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008. http://www.ietf.org/rfc/rfc6078.txt 6078 Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS). G. Camarillo, J. Melen. January 2011. (Format: TXT=3D41482 bytes) (Status: EXPERIMENTAL) Two hosts can use HIP [RFC5201] to establish a security association (SA) between them in order to exchange arbitrary protocol messages over that security association. The establishment of such a security association involves a four-way handshake referred to as the HIP base exchange. When handling communications between the hosts, HIP supports mobility, multihoming, security, and NAT traversal. Some applications require these features for their communications but cannot accept the overhead involved in establishing a security association (i.e., the HIP base exchange) before those communications can start. Once there is a HIP SA between two HIP-enabled hosts, they can exchange further HIP control messages. Typically, UPDATE messages are used. For example, the HIP mobility and multihoming specification [RFC5206] defines how to use UPDATE messages to change the set of IP addresses associated with a HIP SA. [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. http://www.ietf.org/rfc/rfc6079.txt 6079 HIP BONE: Host Identity Protocol (HIP) Based Overlay Networking Environment (BONE). G. Camarillo, P. Nikander, J. Hautakorpi, A. Keranen, A. Johnston. January 2011. (Format: TXT=3D51013 bytes) (Status: EXPERIMENTAL) The Host Identity Protocol (HIP) [RFC5201] defines a new name space between the network and transport layers. HIP provides upper layers with mobility, multihoming, NAT (Network Address Translation) traversal, and security functionality. HIP implements the so-called identifier/locator (ID/locator) split, which implies that IP addresses are only used as locators, not as host identifiers. This split makes HIP a suitable protocol to build overlay networks that implement identifier-based overlay routing over IP networks, which in turn implement locator-based routing. Additionally, having a solution that integrates mobility and multihoming is useful in many scenarios. Peer protocols do not typically specify mobility and multihoming solutions. Combining a peer protocol including NAT traversal with a separate mobility mechanism and a separate multihoming mechanism can easily lead to unexpected (and unpleasant) interactions. In an IP network, IP addresses typically serve two roles: they are used as host identifiers and as host locators. IP addresses are locators because a given host's IP address indicates where in the network that host is located. IP networks route based on these locators. Additionally, IP addresses are used to identify remote hosts. The simultaneous use of IP addresses as host identifiers and locators makes mobility and multihoming complicated. For example, when a host opens a TCP connection, the host identifies the remote end of the connection by the remote IP address (plus port). If the remote host changes its IP address, the TCP connection will not survive, since the transport layer identifier of the remote end of the connection has changed. Mobility solutions such as Mobile IP keep the remote IP address from changing so that it can still be used as an identifier. HIP, on the other hand, uses IP addresses only as locators and defines a new identifier space. This approach is referred to as the ID/locator split and makes the implementation of mobility and multihoming more natural. In the previous example, the TCP connection would be bound to the remote host's identifier, which would not change when the remote hosts moves to a new IP address (i.e., to a new locator). The TCP connection is able to survive locator changes because the remote host's identifier does not change. Once a HIP connection between two hosts has been established with a HIP base exchange, the hosts can start exchanging higher-layer traffic. If any of the hosts changes its set of locators, it runs an update exchange [RFC5206], which consists of three messages. If a host is multihomed, it simply provides more than one locator in its exchanges. However, if both of the endpoints move at the same time, or through some other reason both lose track of the peers' currently active locators, they need to resort to using a rendezvous server or getting new peer locators by some other means. [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. http://www.ietf.org/rfc/rfc6084.txt 6084 General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS). X. Fu, C. Dickmann, J. Crowcroft. January 2011. (Format: TXT=3D27040 bytes) (Status: EXPERIMENTAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 3. GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Association Setup . . . . . . . . . . . . . . . . 5 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Protocol-Definition: Forwards-SCTP . . . . . . . . . . 5 3.2. Effect on GIST State Maintenance . . . . . . . . . . . . . 6 3.3. PR-SCTP Support . . . . . . . . . . . . . . . . . . . . . 6 3.4. API between GIST and NSLP . . . . . . . . . . . . . . . . 7 4. Bit-Level Formats . . . . . . . . . . . . . . . . . . . . . . 7 4.1. MA-Protocol-Options . . . . . . . . . . . . . . . . . . . 7 5. Application of GIST over SCTP . . . . . . . . . . . . . . . . 8 5.1. Multihoming Support of SCTP . . . . . . . . . . . . . . . 8 5.2. Streaming Support in SCTP . . . . . . . . . . . . . . . . 8 6. NAT Traversal Issue . . . . . . . . . . . . . . . . . . . . . 8 7. Use of DTLS with GIST . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 GIST, in its initial specification for Connection mode (C-mode) operation, runs on top of a byte-stream-oriented transport protocol providing a reliable, in-sequence delivery, i.e., using the Transmission Control Protocol (TCP) [9] for signaling message transport. However, some Next Steps in Signaling (NSIS) Signaling Layer Protocol (NSLP) [10] context information has a definite lifetime; therefore, the GIST transport protocol could benefit from flexible retransmission, so stale NSLP messages that are held up by congestion can be dropped. Together with the head-of-line blocking and multihoming issues with TCP, these considerations argue that implementations of GIST should support SCTP as an optional transport protocol for GIST. Like TCP, SCTP supports reliability, congestion control, and fragmentation. Unlike TCP, SCTP provides a number of functions that are desirable for signaling transport, such as multiple streams and multiple IP addresses for path failure recovery. Furthermore, SCTP offers an advantage of message-oriented transport instead of using the byte-stream-oriented TCP where the framing mechanisms must be provided separately. In addition, its Partial Reliability extension (PR-SCTP) [3] supports partial retransmission based on a programmable retransmission timer. Furthermore, DTLS provides a viable solution for securing SCTP [4], which allows SCTP to use almost all of its transport features and its extensions. o How to take advantage of the multihoming support of SCTP. Associations using Forwards-SCTP can carry messages with the transfer attribute Reliable=3DTrue. If an error occurs on the SCTP connection such as a reset, as can be reported by an SCTP socket API notification [11], GIST MUST report this to NSLPs as discussed in Section 4.1.2 of [1]. For the multihoming scenario, when a destination address of a GIST-over-SCTP peer encounters a change, the SCTP API will notify GIST about the availability of different SCTP endpoint addresses and the possible change of the primary path. o "NetworkNotification": According to [1], this primitive "is passed from GIST to a signalling application. It indicates that a network event of possible interest to the signalling application occurred". Here, if SCTP detects a failure of the primary path, GIST SHOULD also indicate this event to the NSLP by calling this primitive with Network-Notification-Type "Routing Status Change". This notification should be done even if SCTP was able to retain an open connection to the peer due to its multihoming capabilities. 5.1. Multihoming Support of SCTP In general, the multihoming support of SCTP can be used to improve fault-tolerance in case of a path or link failure. Thus, GIST over SCTP would be able to deliver NSLP messages between peers even if the primary path is not working anymore. However, for the Message Routing Methods (MRMs) defined in the basic GIST specification, such a feature is only of limited use. The default MRM is path-coupled, which means that if the primary path is failing for the SCTP association, it most likely is also failing for the IP traffic that is signaled for. Thus, GIST would need to perform a refresh to the NSIS nodes to the alternative path anyway to cope with the route change. When the two endpoints of a multihomed SCTP association (but none of the intermediate nodes between them) support NSIS, GIST over SCTP provides a robust means for GIST to deliver NSLP messages even when the primary path fails but at least one alternative path between these (NSIS-enabled) endpoints of the multihomed path is available. Additionally, the use of the multihoming support of SCTP provides GIST and the NSLP with another source to detect route changes. Furthermore, for the time between detection of the route change and recovering from it, the alternative path offered by SCTP can be used by the NSLP to make the transition more smoothly. Finally, future MRMs might have different properties and therefore benefit from multihoming more broadly. http://www.ietf.org/rfc/rfc6089.txt 6089 Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support. G. Tsirtsis, H. Soliman, N. Montavont, G. Giaretta, K. Kuladinithi. January 2011. (Format: TXT=3D69353 bytes) (Updates RFC5648) (Status: PROPOSED STANDARD) This document introduces extensions to Mobile IPv6 that allow nodes to bind one or more flows to a care-of address. These extensions allow multihomed nodes to instruct home agents and other Mobile IPv6 entities to direct inbound flows to specific addresses. http://www.ietf.org/rfc/rfc6092.txt 6092 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service. J. Woodyatt, Ed.. January 2011. (Format: TXT=3D91729 bytes) (Status: INFORMATIONAL) 1. Introduction ....................................................3 1.1. Special Language ...........................................3 1.2. Use of Normative Keywords ..................................3 2. Overview ........................................................4 2.1. Basic Sanitation ...........................................5 2.2. Internet Layer Protocols ...................................5 2.3. Transport Layer Protocols ..................................6 3. Detailed Recommendations ........................................6 3.1. Stateless Filters ..........................................7 3.2. Connection-Free Filters ....................................8 3.2.1. Internet Control and Management .....................8 3.2.2. Upper-Layer Transport Protocols .....................8 3.2.3. UDP Filters ........................................10 3.2.4. IPsec and Internet Key Exchange (IKE) ..............11 3.2.5. Mobility Support in IPv6 ...........................12 3.3. Connection-Oriented Filters ...............................13 3.3.1. TCP Filters ........................................14 3.3.2. SCTP Filters .......................................17 3.3.3. DCCP Filters .......................................20 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (Shim6) ............................................23 3.4. Passive Listeners .........................................23 3.5. Management Applications ...................................24 4. Summary of Recommendations .....................................25 5. Contributors ...................................................31 6. Security Considerations ........................................32 7. References .....................................................33 7.1. Normative References ......................................33 7.2. Informative References ....................................35 3.3.4. Level 3 Multihoming Shim Protocol for IPv6 (Shim6) While IPv6 simple security is applicable to residential networks with only one Internet service provider at a time, the use of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6) [RFC5533] is necessary for communications with some multihomed exterior destinations. No special recommendations are made in this document for processing the Shim6 message format (protocol 140) beyond the recommendations in Section 3.2.2. The content of the Shim6 payload extension header may be ignored. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. http://www.ietf.org/rfc/rfc6104.txt 6104 Rogue IPv6 Router Advertisement Problem Statement. T. Chown, S. Venaas. February 2011. (Format: TXT=3D36518 bytes) (Status: INFORMATIONAL) After a host receives and processes a rogue RA, it may have multiple default gateways, global addresses, and potentially clashing RA options (e.g., M/O bits [RFC4861]). The host's behaviour may then be unpredictable, in terms of the default router that is used, and the (source) address(es) used in communications. A host that is aware of protocols such as Shim6 [RFC5533] may believe it is genuinely multihomed. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. http://www.ietf.org/rfc/rfc6115.txt 6115 Recommendation for a Routing Architecture. T. Li, Ed.. February 2011. (Format: TXT=3D178526 bytes) (Status: INFORMATIONAL) It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group. 11. Tunneled Inter-Domain Routing (TIDR) . . . . . . . . . . . . . 40 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 40 11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 40 11.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 40 11.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 41 11.1.4. References . . . . . . . . . . . . . . . . . . . . . . 41 11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 41 11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 42 12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 42 12.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 42 12.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 42 12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 43 12.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 44 12.1.4. References . . . . . . . . . . . . . . . . . . . . . . 45 12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 45 12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. Enhanced Efficiency of Mapping Distribution Protocols in Map-and-Encap Schemes (EEMDP) . . . . . . . . . . . . . . . . 48 13.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48 13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 48 13.1.2. Management of Mapping Distribution of Subprefixes Spread across Multiple ETRs . . . . . . . . . . . . . 48 13.1.3. Management of Mapping Distribution for Scenarios with Hierarchy of ETRs and Multihoming . . . . . . . . 49 13.1.4. References . . . . . . . . . . . . . . . . . . . . . . 50 13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 50 13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 51 14. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 52 14.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 52 14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 52 14.1.2. Relation to Other RRG Proposals . . . . . . . . . . . 53 14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 53 14.1.4. References . . . . . . . . . . . . . . . . . . . . . . 55 14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 55 14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 56 15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 56 15.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56 15.1.1. References . . . . . . . . . . . . . . . . . . . . . . 58 15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 58 15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 59 15.2.2. Edge-networks . . . . . . . . . . . . . . . . . . . . 59 15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 59 16. Routing and Addressing in Networks with Global Enterprise Recursion (IRON-RANGER) . . . . . . . . . . . . . . . . . . . 59 16.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 59 16.1.1. Gains . . . . . . . . . . . . . . . . . . . . . . . . 60 16.1.2. Costs . . . . . . . . . . . . . . . . . . . . . . . . 61 16.1.3. References . . . . . . . . . . . . . . . . . . . . . . 61 It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. The problem being addressed has been documented in [Scalability_PS], and the design goals that we have discussed can be found in [RRG_Design_Goals]. 10. The Research Group has consensus that the Internet needs to support multihoming in a manner that scales well and does not have prohibitive costs. 11. Any IETF solution to Internet scaling has to not only support multihoming, but address the real-world constraints of the end customers (large and small). LISP's ITRs' multihoming service restoration depends on their determining the reachability of end-user networks via two or more ETRs. Large numbers of ITRs doing this is inefficient and may overburden ETRs. LISP monolithically integrates multihoming failure detection and restoration decision-making processes into the Core-Edge Separation (CES) scheme itself. End-user networks must rely on the necessarily limited capabilities that are built into every ITR. 2. Traffic Engineering: Hosts located in a multihomed site can suggest the upstream ISP for outbound and inbound traffic, while the first-hop Locator Domain Border Router (LDBR; i.e., site border router) has the final decision on the upstream ISP selection. 3. Mobility and Multihoming: Sessions will not be interrupted due to locator change in cases of mobility or multihoming. RANGI provides strong sender identification, but at the cost of computing crypto. Many hosts (public web servers) may prefer to forgo the crypto at the expense of losing some functionality (receiver mobility or dynamic multihoming load balancing). While RANGI doesn't require that the receiver validate the sender, it may be good to have a mechanism whereby the receiver can signal to the sender that it is not validating, so that the sender can avoid locator changes. Ivip (pronounced eye-vip, est. 2007-06-15) is a Core-Edge Separation scheme for IPv4 and IPv6. It provides multihoming, portability of address space, and inbound traffic engineering for end-user networks of all sizes and types, including those of corporations, SOHO (Small Office, Home Office), and mobile devices. End-user networks control the mapping, typically by contracting a specialized company to monitor the reachability of their ETRs, and change the mapping to achieve multihoming and/or traffic engineering (TE). So, the mechanisms that control ITR tunneling are controlled by the end-user networks in real-time and are completely separate from the Core-Edge Separation scheme itself. Default ITRs in the DFZ (DITRs; similar to LISP's Proxy Tunnel Routers) tunnel packets sent by hosts in networks that lack ITRs. So multihoming, portability, and TE benefits apply to all traffic. The maximum number of non-mobile networks requiring multihoming, etc., is likely to be ~10 million, so most of the 10 billion mappings would be for mobile devices. However, TTR mobility does not involve frequent mapping changes since most MNs only rarely move more than 1000 km. The critique implies a threshold of adoption is required before significant routing scaling benefits occur. This is untrue of any Core-Edge Separation proposal, including LISP and Ivip. Both can achieve scalable routing benefits in direct proportion to their level of adoption by providing portability, multihoming, and inbound TE to large numbers of end-user networks. The Hierarchical IPv4 Framework (hIPv4) adds scalability to the routing architecture by introducing additional hierarchy in the IPv4 address space. The IPv4 addressing scheme is divided into two parts, the Area Locator (ALOC) address space, which is globally unique, and the Endpoint Locator (ELOC) address space, which is only regionally unique. The ALOC and ELOC prefixes are added as a shim header between the IP header and transport protocol header; the shim header is identified with a new protocol number in the IP header. Instead of creating a tunneling (i.e., overlay) solution, a new routing element is needed in the service provider's routing domain (called ALOC realm) -- a Locator Swap Router. The current IPv4 forwarding plane remains intact, and no new routing protocols, mapping systems, or caching solutions are required. The control plane of the ALOC realm routers needs some modification in order for ICMP to be compatible with the hIPv4 framework. When an area (one or several autonomous systems (ASes)) of an ISP has transformed into an ALOC realm, only ALOC prefixes are exchanged with other ALOC realms. Directly attached ELOC prefixes are only inserted to the RIB of the local ALOC realm; ELOC prefixes are not distributed to the DFZ. Multihoming can be achieved in two ways, either the enterprise requests an ALOC prefix from the RIR (this is not recommended) or the enterprise receives the ALOC prefixes from their upstream ISPs. ELOC prefixes are PI addresses and remain intact when an upstream ISP is changed; only the ALOC prefix is replaced. When the RIB of the DFZ is compressed (containing only ALOC prefixes), ingress routers will no longer know the availability of the destination prefix; thus, the endpoints must take more responsibility for their sessions. This can be achieved by using multipath enabled transport protocols, such as SCTP [RFC4960] and Multipath TCP (MPTCP) [MPTCP_Arch], at the endpoints. The multipath transport protocols also provide a session identifier, i.e., verification tag or token; thus, the location and identifier split is carried out -- site mobility, endpoint mobility, and mobile site mobility are achieved. DNS needs to be upgraded: in order to resolve the location of an endpoint, the endpoint must have one ELOC value (current A-record) and at least one ALOC value in DNS (in multihoming solutions there will be several ALOC values for an endpoint). 3. Scalable support for multihoming: Only attachment points of a multihomed site are advertised (using the ALOC prefix) in the DFZ. DNS will inform the requester on how many attachment points the destination endpoint has. It is the initiating endpoint's choice/responsibility to choose which attachment point is used for the session; endpoints using multipath-enabled transport protocols can make use of several attachment points for a session. 2. In a multihoming solution, the border routers should be able to apply policy-based routing upon the ALOC value in the locator header. Ivip and LISP appear to have a major advantage over hIPv4 in terms of support for packets sent from non-upgraded hosts/networks. Ivip's DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel Routers) both accept packets sent by any non-upgraded host/network and tunnel them to the correct ETR -- thus providing the full benefits of portability, multihoming, and inbound TE for these packets as well as those sent by hosts in networks with ITRs. hIPv4 appears to have no such mechanism, so these benefits are only available for communications between two upgraded hosts in upgraded networks. This means that significant benefits for adopters -- the ability to rely on the new system to provide the portability, multihoming, and inbound TE benefits for all, or almost all, their communications -- will only arise after all, or almost all, networks upgrade their networks, hosts, and addressing arrangements. hIPv4's relationship between adoption levels and benefits to any adopter therefore are far less favorable to widespread adoption than those of Core-Edge Separation (CES) architectures such as Ivip and LISP. 3. Multihoming: When a PI addressed network connects to the Internet by multihoming with several providers, it can deploy NTRs to prevent the PI addresses from leaking into provider networks. 5. In the Core-Edge Separation scenario, the requirement for multihoming and inter-domain traffic engineering will make end sites accessible via multiple different NTRs. For reliability, all of the associations between multiple NTRs and the end site name will be kept in DNS, which may increase the load on DNS. NOL resembles neither CEE nor CES as a solution. By supporting application-level sessions through the name overlay layer, NOL can support some solutions in the CEE style. However, NOL is in general closer to CES solutions, i.e., preventing PI prefixes of edge networks from entering into the upstream transit networks. This is done by the NTR, like the ITRs/ETRs in CES solutions, but NOL has no need to define the clear boundary between core and edge networks. NOL is designed to try to provide end users or networks a service that facilitates the adoption of multihoming, multipath routing, and traffic engineering by the indirect routing through NTRs, and that, in the mean time, doesn't accelerate or decelerate the growth of global routing table size. o Multihoming o Multihoming resilience Multihoming service restoration is achieved initially by the ETR-like function of the BR at the ISP (whose link to the end-user network has just failed). It looks up the mapping to find the next preferred ETR-like BR's address. The first ETR-like router tunnels the packets to the second ETR-like router in the other ISP. However, if the failure was caused by the first ISP itself being unreachable, then connectivity would not be restored until a revised mapping (with higher REMOTE-PREFERENCE) from the reachable ETR-like BR of the second ISP propagated across the DFZ to all ITR-like routers, or the withdrawn advertisement for the first one reaches the ITR-like router. o The underlying protocol mechanisms support fully scalable site multihoming, node multihoming, site mobility, and node mobility. Also, ILNP enables both host multihoming and site multihoming. Current BGP approaches cannot support host multihoming. Host multihoming is valuable in reducing the site's set of externally visible nodes. 13.1.3. Management of Mapping Distribution for Scenarios with Hierarchy of ETRs and Multihoming essence, they can allow ETR7 to act as the locator for the delivery networks in their purview. ETR7 keeps a local mapping table for mapping the appropriate EID address space to specific ETRs that are hierarchically associated with it in the level below. In this situation, ETR7 can perform EID address space aggregation across ETRs 1 through 3 and can also include its own immediate EID address space for the purpose of that aggregation. The many details related to this approach and special circumstances involving multihoming of subnets are discussed in detail in [EEMDP_Considerations]. The hierarchical organization of ETRs and delivery networks should help in the future growth and scalability of ETRs and mapping distribution networks. This is essentially recursive map-and-encap, and some of the mapping distribution and management functionality will remain local to topologically neighboring delivery networks that are hierarchically underneath ETRs. A particularly positive effect of name-based sockets on Internet routing scalability is the new incentives for edge network operators to use provider-assigned IP addresses, which are more aggregatable than the typically preferred provider-independent IP addresses. Even though provider-independent IP addresses are harder to get and more expensive than provider-assigned IP addresses, many operators desire provider-independent addresses due to the high indirect cost of provider-assigned IP addresses. This indirect cost is comprised of both difficulties in multihoming, and tedious and largely manual renumbering upon provider changes. Name-based sockets reduce the indirect cost of provider-assigned IP addresses in three ways, and hence make the use of provider-assigned IP addresses more acceptable: (1) They enable fine-grained and responsive multihoming. (2) They simplify renumbering by offering an easy means to replace IP addresses in referrals with domain names. This helps avoiding updates to application and operating system configurations, scripts, and databases during renumbering. (3) They facilitate low-cost solutions that eliminate renumbering altogether. One such low-cost solution is IP address translation, which in combination with name-based sockets loses its adverse impact on applications. The main incentives and drivers are geared towards the transition of applications to the name-based sockets. Adoption by applications will be driven by benefits in terms of reduced application development cost. Legacy applications are expected to migrate to the new API at a slower pace, as the name-based sockets are backwards compatible, this can happen in a per-host fashion. Also, not all applications can be ported to a FQDN dependent infrastructure, e.g., DNS functions. This hurdle is manageable, and may not be a definite obstacle for the transition of a whole domain, but it needs to be taken into account when striving for mobility/multihoming of an entire site. The transition of functions on individual hosts may be trivial, either through upgrades/changes to the OS or as linked libraries. This can still happen incrementally and independently, as compatibility is not affected by the use of name-based sockets. o support for site multihoming and traffic engineering o ingress filtering for multihomed sites There is no provision for RANGER's ITR-like routers being able to probe the reachability of end-user networks via multiple ETR-like routers -- nor for any other approach to multihoming service restoration. CEs can move from old RANGER networks and re-inject their PI prefixes into new RANGER networks. This would be accommodated by IRON-RANGER as a site multihoming event while host mobility and true locator-ID separation is accommodated via HIP [RFC5201]. [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009. http://www.ietf.org/rfc/rfc6139.txt 6139 Routing and Addressing in Networks with Global Enterprise Recursion (RANGER) Scenarios. S. Russert, Ed., E. Fleischman, Ed., = F. Templin, Ed.. February 2011. (Format: TXT=3D101101 bytes) (Status: INFORMATIONAL) "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)" (RFC 5720) provides an architectural framework for scalable routing and addressing. It provides an incrementally deployable approach for scalability, provider independence, mobility, multihoming, traffic engineering, and security. This document describes a series of use cases in order to showcase the architectural capabilities. It further shows how the RANGER architecture restores the network-within-network principles originally intended for the sustained growth of the Internet. RANGER provides an architectural framework for scalable routing and addressing. It provides for scalability, provider independence, mobility, multihoming, and security for the next-generation Internet. The RANGER architectural principles are not new. They can be traced to the deliberations of the ROAD group [RFC1380], and also to still earlier works including NIMROD [RFC1753] and the Catenet model for internetworking [CATENET] [IEN48] [RFC2775]. [RFC1955] captures the high-level architectural aspects of the ROAD group deliberations in a "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG". painful" Host Density (HD) ratio threshold of 86% (that is, 192M allocated addresses) [RFC3194]. As a result, exhaustion of the IPv4 address pool is predicted within the next two years [IPv4POOL], [HUSTON-END]. IPv6 promises to resolve the address shortage with a much larger address space, but transition is costly and could exacerbate BGP problems described below. Richer interconnection, increased multihoming (especially with provider-independent (PI) addresses), and a desire to support traffic engineering via finer control of routing has led to super-linear growth of BGP routing tables in the Default-Free Zone, or "DFZ", of the Internet. This growth is placing increasing pressures on router capacities and technology costs that are unsustainable for the longer term within the current Internet routing framework. Each enterprise network operator must be able to manage its internal networks and use the Internet infrastructure to achieve its performance and reliability goals. Enterprise networks that are multihomed or have mobile components frequently require provider- independent addressing and the ability to coordinate with multiple providers without renumbering "flag days" [RFC4192] [RFC5887]. RANGER provides a way to coordinate addressing plans and inter-enterprise routing, with full support for scalability, provider independence, mobility, multihoming, and security. The scenarios discussed in this document have not closely examined future growth of the native IPv6 and IPv4 Internets independently of any growth in RANGER overlay networking. For example, it is likely that current-day major Internet services that support millions of customers simultaneously (e.g., Google, Yahoo, eBay, Amazon, etc.) will continue to be served best by native Internet routing and addressing rather than by overlay network arrangements that require dynamic mapping state coordination. At the same time, however, more and more small end user networks will wish to use provider- independent addressing for multihoming via multiple ISPs as well as support traffic engineering and mobility management. http://www.ietf.org/rfc/rfc6147.txt 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I. = van Beijnum. April 2011. (Format: TXT=3D75103 bytes) (Status: PROPOSED STANDARD) 1. Introduction ....................................................4 2. Overview ........................................................5 3. Background to DNS64-DNSSEC Interaction ..........................7 4. Terminology .....................................................9 5. DNS64 Normative Specification ..................................10 5.1. Resolving AAAA Queries and the Answer Section .............11 5.1.1. The Answer when There is AAAA Data Available .......11 5.1.2. The Answer when There is an Error ..................11 5.1.3. Dealing with Timeouts ..............................12 5.1.4. Special Exclusion Set for AAAA Records .............12 5.1.5. Dealing with CNAME and DNAME .......................12 5.1.6. Data for the Answer when Performing Synthesis ......13 5.1.7. Performing the Synthesis ...........................13 5.1.8. Querying in Parallel ...............................14 5.2. Generation of the IPv6 Representations of IPv4 Addresses ..14 5.3. Handling Other Resource Records and the Additional Section ...................................................15 5.3.1. PTR Resource Record ................................15 5.3.2. Handling the Additional Section ....................16 5.3.3. Other Resource Records .............................17 5.4. Assembling a Synthesized Response to a AAAA Query .........17 5.5. DNSSEC Processing: DNS64 in Validating Resolver Mode ......17 6. Deployment Notes ...............................................19 6.1. DNS Resolvers and DNS64 ...................................19 6.2. DNSSEC Validators and DNS64 ...............................19 6.3. DNS64 and Multihomed and Dual-Stack Hosts .................19 6.3.1. IPv6 Multihomed Hosts ..............................19 6.3.2. Accidental Dual-Stack DNS64 Use ....................20 6.3.3. Intentional Dual-Stack DNS64 Use ...................21 7. Deployment Scenarios and Examples ..............................21 7.1. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in DNS Server Mode .......................22 7.2. Example of "an IPv6 Network to the IPv4 Internet" Setup with DNS64 in Stub-Resolver Mode ....................23 7.3. Example of "the IPv6 Internet to an IPv4 Network" Setup with DNS64 in DNS Server Mode .......................24 8. Security Considerations ........................................27 9. Contributors ...................................................27 10. Acknowledgements ..............................................27 11. References ....................................................28 11.1. Normative References .....................................28 11.2. Informative References ...................................28 Appendix A. Motivations and Implications of Synthesizing AAAA Resource Records when Real AAAA Resource Records Exist ................................................30 6.3. DNS64 and Multihomed and Dual-Stack Hosts 6.3.1. IPv6 Multihomed Hosts Figure 1: IPv6 Multihomed Hosts http://www.ietf.org/rfc/rfc6177.txt 6177 IPv6 Address Assignment to End Sites. T. Narten, G. Huston, L. Roberts. March 2011. (Format: TXT=3D21231 bytes) (Obsoletes = RFC3177) (Also BCP0157) (Status: BEST CURRENT PRACTICE) RFC 3177 suggested that some multihoming approaches (e.g., Generalized Structure Element (GSE)) might benefit from having a fixed /48 boundary. This no longer appears to be a consideration. http://www.ietf.org/rfc/rfc6179.txt 6179 The Internet Routing Overlay Network (IRON). F. Templin, Ed.. March 2011. (Format: TXT=3D92638 bytes) (Status: EXPERIMENTAL) Since the Internet must continue to support escalating growth due to increasing demand, it is clear that current routing architectures and operational practices must be updated. This document proposes an Internet Routing Overlay Network (IRON) that supports sustainable growth while requiring no changes to end systems and no changes to the existing routing system. IRON further addresses other important issues including routing scaling, mobility management, multihoming, traffic engineering and NAT traversal. While business considerations are an important determining factor for widespread adoption, they are out of scope for this document. This document is a product of the IRTF Routing Research Group. 1. Introduction ....................................................4 2. Terminology .....................................................5 3. The Internet Routing Overlay Network ............................7 3.1. IRON Client ................................................9 3.2. IRON Serving Router .......................................10 3.3. IRON Relay Router .........................................10 4. IRON Organizational Principles .................................11 5. IRON Initialization ............................................13 5.1. IRON Relay Router Initialization ..........................13 5.2. IRON Serving Router Initialization ........................14 5.3. IRON Client Initialization ................................15 6. IRON Operation .................................................15 6.1. IRON Client Operation .....................................16 6.2. IRON Serving Router Operation .............................17 6.3. IRON Relay Router Operation ...............................18 6.4. IRON Reference Operating Scenarios ........................18 6.4.1. Both Hosts within IRON EUNs ........................19 6.4.2. Mixed IRON and Non-IRON Hosts ......................21 6.5. Mobility, Multihoming, and Traffic Engineering Considerations ............................................24 6.5.1. Mobility Management ................................24 6.5.2. Multihoming ........................................25 6.5.3. Inbound Traffic Engineering ........................25 6.5.4. Outbound Traffic Engineering .......................25 6.6. Renumbering Considerations ................................25 6.7. NAT Traversal Considerations ..............................26 6.8. Multicast Considerations ..................................26 6.9. Nested EUN Considerations .................................26 6.9.1. Host A Sends Packets to Host Z .....................28 6.9.2. Host Z Sends Packets to Host A .....................28 7. Implications for the Internet ..................................29 8. Additional Considerations ......................................30 9. Related Initiatives ............................................30 10. Security Considerations .......................................31 11. Acknowledgements ..............................................31 12. References ....................................................32 12.1. Normative References .....................................32 12.2. Informative References ...................................32 Appendix A. IRON VPs over Internetworks with Different Address Families ......................................35 Appendix B. Scaling Considerations ................................36 Growth in the number of entries instantiated in the Internet routing system has led to concerns regarding unsustainable routing scaling [RADIR]. Operational practices such as the increased use of multihoming with Provider-Independent (PI) addressing are resulting in more and more fine-grained prefixes being injected into the routing system from more and more end user networks. Furthermore, depletion of the public IPv4 address space has raised concerns for both increased address space fragmentation (leading to yet further routing table entries) and an impending address space run-out scenario. At the same time, the IPv6 routing system is beginning to see growth [BGPMON] which must be managed in order to avoid the same routing scaling issues the IPv4 Internet now faces. Since the Internet must continue to scale to accommodate increasing demand, it is clear that new routing methodologies and operational practices are needed. The IRON is a global routing system comprising virtual overlay networks managed by Virtual Prefix Companies (VPCs) that own and manage Virtual Prefixes (VPs) from which End User Network (EUN) prefixes (EPs) are delegated to customer sites. The IRON is motivated by a growing customer demand for multihoming, mobility management, and traffic engineering while using stable addressing to minimize dependence on network renumbering [RFC4192][RFC5887]. The IRON uses the existing IPv4 and IPv6 global Internet routing systems as virtual NBMA links for tunneling inner network protocol packets within outer IPv4 or IPv6 headers (see Section 3). The IRON requires deployment of a small number of new BGP core routers and supporting servers, as well as IRON-aware routers/servers in customer EUNs. No modifications to hosts, and no modifications to most routers, are required. After selecting its Server as specified in Section 5.3, the Client should register each of its ISP connections with the Server for multihoming purposes. To do so, it sends periodic beacons (e.g., SRS messages) to its Server via each of its ISPs to establish additional tunnel-neighbor state. This implies that a single tunnel-neighbor identifier (i.e., a "nonce") is used to represent the set of all ISP paths between the Client and the Server. Therefore, the nonce names this "bundle" of ISP paths. 6.5. Mobility, Multihoming, and Traffic Engineering Considerations While IRON Servers and Relays can be considered as fixed infrastructure, Clients may need to move between different network points of attachment, connect to multiple ISPs, or explicitly manage their traffic flows. The following sections discuss mobility, multihoming, and traffic engineering considerations for IRON client routers. 6.5.2. Multihoming A Client may register multiple locators with its Server. It can assign metrics with its registrations to inform the Server of preferred locators, and it can select outgoing locators according to its local preferences. Therefore, multihoming is naturally supported. Finally, and perhaps most importantly, the IRON system provides an in-built mobility management and multihoming capability that allows end user devices and networks to move about freely while both imparting minimal oscillations in the routing system and maintaining generally shortest-path routes. This mobility management is afforded through the very nature of the IRON customer/provider relationship, and therefore requires no adjunct mechanisms. The mobility management and multihoming capabilities are further supported by forward-path reachability detection that provides "hints of forward progress" in the same spirit as for IPv6 Neighbor Discovery (ND). Considerations for the scalability of Internet Routing due to multihoming, traffic engineering, and provider-independent addressing are discussed in [RADIR]. Other scaling considerations specific to IRON are discussed in Appendix B. http://www.ietf.org/rfc/rfc6181.txt 6181 Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses. M. Bagnulo. March 2011. (Format: TXT=3D44251 = bytes) (Status: INFORMATIONAL) Multipath TCP (MPTCP for short) describes the extensions proposed for TCP so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. Multipath TCP (MPTCP for short) describes the extensions proposed for TCP [RFC0793] so that endpoints of a given TCP connection can use multiple paths to exchange data. Such extensions enable the exchange of segments using different source-destination address pairs, resulting in the capability of using multiple paths in a significant number of scenarios. Some level of multihoming and mobility support can be achieved through these extensions. However, the support for multiple IP addresses per endpoint may have implications on the security of the resulting MPTCP. This note includes a threat analysis for MPTCP. There are many other ways to provide multiple paths for a TCP connection other than the usage of multiple addresses. The threat analysis performed in this document is limited to the specific case of using multiple addresses per endpoint. [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. http://www.ietf.org/rfc/rfc6182.txt 6182 Architectural Guidelines for Multipath TCP Development. A. Ford, C. Raiciu, M. Handley, S. Barre, J. Iyengar. March 2011. (Format: TXT=3D68772 bytes) (Status: INFORMATIONAL) Multipath TCP is a modified version of TCP [1] that implements a multipath transport and achieves these goals by pooling multiple paths within a transport connection, transparently to the application. Multipath TCP is primarily concerned with utilizing multiple paths end-to-end, where one or both of the end hosts are multihomed. It may also have applications where multiple paths exist within the network and can be manipulated by an end host, such as using different port numbers with Equal Cost MultiPath (ECMP) [4]. Although multihoming and multipath functions are not new to transport protocols (Stream Control Transmission Protocol (SCTP) [6] being a notable example), MPTCP aims to gain wide-scale deployment by recognizing the importance of application and network compatibility goals. These goals, discussed in detail in Section 2, relate to the appearance of MPTCP to the network (so non-MPTCP-aware entities see it as TCP) and to the application (through providing a service equivalent to TCP for non-MPTCP-aware applications). The diagram shown in Figure 1 illustrates a typical usage scenario for Multipath TCP. Two hosts, A and B, are communicating with each other. These hosts are multihomed and multi-addressed, providing two disjoint connections to the Internet. The addresses on each host are referred to as A1, A2, B1, and B2. There are therefore up to four different paths between the two hosts: A1-B1, A1-B2, A2-B1, A2-B2. There are several similarities between SCTP [6] and MPTCP, in that both can make use of multiple addresses at end hosts to give some multipath capability. In SCTP, the primary use case is to support redundancy and mobility for multihomed hosts (i.e., a single path will change one of its end host addresses); the simultaneous use of multiple paths is not supported. Extensions are proposed to support simultaneous multipath transport [13], but these are yet to be standardized. By far the most widely used stream-based transport protocol is, however, TCP [1], and SCTP does not meet the network and application compatibility goals specified in Section 2.2. For network compatibility, there are issues with various middleboxes (especially NATs) that are unaware of SCTP and consequently end up blocking it. For application compatibility, applications need to actively choose to use SCTP, and with the deployment issues, very few choose to do so. MPTCP's compatibility goals are in part based on these observations of SCTP's deployment issues. http://www.ietf.org/rfc/rfc6192.txt 6192 Protecting the Router Control Plane. D. Dugal, C. Pignataro, R. Dunn. March 2011. (Format: TXT=3D49422 bytes) (Status: = INFORMATIONAL) [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. http://www.ietf.org/rfc/rfc6204.txt 6204 Basic Requirements for IPv6 Customer Edge Routers. H. Singh, W. Beebee, C. Donley, B. Stark, O. Troan, Ed.. April 2011. (Format: TXT=3D37026 bytes) (Status: INFORMATIONAL) Rewriting addresses on the edge of the network also allows for some rudimentary multihoming, even though using NATs for multihoming does not preserve connections during a fail-over event [RFC4864]. A dual-stack host is multihomed to IPv4 and IPv6 networks. The IPv4 and IPv6 topologies may not be congruent, and different addresses may have different reachability, e.g., ULAs. A host stack has to be able to quickly fail over and try a different source address and destination address pair if communication fails, as outlined in [HAPPY-EYEBALLS]. At the time of this writing, several host implementations do not handle the case where they have an IPv6 address configured and no IPv6 connectivity, either because the address itself has a limited topological reachability (e.g., ULA) or because the IPv6 CE router is not connected to the IPv6 network on its WAN interface. To support host implementations that do not handle multihoming in a multi-prefix environment [MULTIHOMING-WITHOUT-NAT], the IPv6 CE router should not, as detailed in the requirements below, advertise itself as a default router on the LAN interface(s) when it does not have IPv6 connectivity on the WAN interface or when it is not provisioned with IPv6 addresses. For local IPv6 communication, the mechanisms specified in [RFC4191] are used. [MULTIHOMING-WITHOUT-NAT] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, March 2011. http://www.ietf.org/rfc/rfc6214.txt 6214 Adaptation of RFC 1149 for IPv6. B. Carpenter, R. Hinden. April 1 2011. (Format: TXT=3D15073 bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Normative Notation . . . . . . . . . . . . . . . . . . . . . . 2 3. Detailed Specification . . . . . . . . . . . . . . . . . . . . 2 3.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . . 2 3.2. Frame Format . . . . . . . . . . . . . . . . . . . . . . . 3 3.3. Address Configuration . . . . . . . . . . . . . . . . . . . 3 3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Quality-of-Service Considerations . . . . . . . . . . . . . . . 4 5. Routing and Tunneling Considerations . . . . . . . . . . . . . 4 6. Multihoming Considerations . . . . . . . . . . . . . . . . . . 5 7. Internationalization Considerations . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . . 6 6. Multihoming Considerations Some types of carriers are notoriously good at homing. Surprisingly, this property is not mentioned in RFC 1149. Unfortunately, they prove to have no talent for multihoming, and in fact enter a routing loop whenever multihoming is attempted. This appears to be a fundamental restriction on the topologies in which both RFC 1149 and the present specification can be deployed. http://www.ietf.org/rfc/rfc6224.txt 6224 Base Deployment for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) Domains. T. Schmidt, M. Waehlisch, S. Krishnan. April 2011. (Format: TXT=3D46105 bytes) (Status: INFORMATIONAL) 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Deployment Details . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Operations of the Mobile Node . . . . . . . . . . . . . . 8 4.2. Operations of the Mobile Access Gateway . . . . . . . . . 8 4.3. Operations of the Local Mobility Anchor . . . . . . . . . 10 4.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . 10 4.5. Multihoming Support . . . . . . . . . . . . . . . . . . . 11 4.6. Multicast Availability throughout the Access Network . . . 12 4.7. A Note on Explicit Tracking . . . . . . . . . . . . . . . 12 5. Message Source and Destination Address . . . . . . . . . . . . 13 5.1. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Report/Done . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 Appendix A. Initial MLD Queries on Upcoming Links . . . . . . . . 16 Appendix B. State of IGMP/MLD Proxy Implementations . . . . . . . 16 Appendix C. Comparative Evaluation of Different Approaches . . . 17 4.5. Multihoming Support --Apple-Mail-93--700698807-- From paul.hoffman@vpnc.org Fri Apr 29 06:29:46 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFC7E06B7 for ; Fri, 29 Apr 2011 06:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.551 X-Spam-Level: X-Spam-Status: No, score=-101.551 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMvNCjpclQzU for ; Fri, 29 Apr 2011 06:29:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA5DE0674 for ; Fri, 29 Apr 2011 06:29:45 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3TDTfxk023141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Apr 2011 06:29:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <3E4B2789-F5AC-4E9E-BEE7-BA36C9DEB481@cisco.com> Date: Fri, 29 Apr 2011 06:29:41 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B319C0B03B24079A1FA152C36A6FF2D@davidPC> <3E4B2789-F5AC-4E9E-BEE7-BA36C9DEB481@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: David Harrington , tools-discuss@ietf.org Subject: Re: [Tools-discuss] RFC search engine X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 13:29:46 -0000 On Apr 28, 2011, at 1:53 PM, Fred Baker wrote: > I have built myself a few ad hoc tools that build on an internet draft = or RFC mirror I keep on my laptop, but to be honest I'm not happy with = them. Not related to David's original request, but relevant to that point: = Russ Housley and I have also been developing such tools and are = tentatively scheduled to bring them to the tools team in May. Our hope = is that they can be released to those in the community who want such = tools but don't want to write themselves. Look for more from us in a = bit. > I do a lot of old-fashioned grepping. We don't do that for the content, but we do do it for the filenames. = Thus, you can say "draft baker" and get all the drafts that have "baker" = in the filename. I'd be happy to consider how we could put in some = content searching as well. Our intention was that these tools could be delivered from the Tools = site but would not be considered actual Tools Team products. --Paul Hoffman From Jeff.Hodges@KingsMountain.com Fri Apr 29 08:38:15 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A8BE06A7 for ; Fri, 29 Apr 2011 08:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.942 X-Spam-Level: X-Spam-Status: No, score=-101.942 tagged_above=-999 required=5 tests=[AWL=0.657, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGr8RizSv-84 for ; Fri, 29 Apr 2011 08:38:11 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 1DE0AE0663 for ; Fri, 29 Apr 2011 08:38:11 -0700 (PDT) Received: (qmail 28433 invoked by uid 0); 29 Apr 2011 15:38:10 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 29 Apr 2011 15:38:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=YwWqF+vquYxOV2avhi7BDLhXtDc1ZhCgRO+c1RZL9MIvXg4wNVYBPXgkVYDOUVgiLQFP2jIxdWhqYgzwiwqzDIhn3pPKR1WBd7+0ziqZA/O6FUAkSAtO2KC4/XZxkzFH; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.202]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1QFpli-0005L0-Bn for tools-discuss@ietf.org; Fri, 29 Apr 2011 09:38:10 -0600 Message-ID: <4DBADB62.10603@KingsMountain.com> Date: Fri, 29 Apr 2011 08:38:10 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8 MIME-Version: 1.0 To: IETF Tools List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [Tools-discuss] RFC search engine X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 15:38:15 -0000 > Our intention was that these tools could be delivered from the Tools site > but would not be considered actual Tools Team products. when I was at Xerox back in the 80s, we had a similar notion for ad-hoc tools that were shared with the community. By convention, we called 'em "hacks" (not too surprisingly), and had a central distribution point for them. One could easily write a hack and share it with the internal (largely developers) community. There were some written informal rules (sorta "social norms wrt hacks"; there were kept on the hacks file server), similar to.. "thou shalt provide a modicum of documentation when submitting a hack, shalt submit both source and binary; anyone can hack on any hack, tho by touching it, you may then own it; you use hacks at your own risk, but if you wrote a hack that's useful for getting real work done, and you're the current maintainer, then you're kinda obliged to engage if someone brings a bug to your attention, tho resolution and all is negotiable; its poor form to publish a poorly-tested hack, especially if its aimed at helping get real work done; etc ..." I can imagine a similar set of norms working in this community. =JeffH From paul.hoffman@vpnc.org Fri Apr 29 09:31:54 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D167EE06AB for ; Fri, 29 Apr 2011 09:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.621 X-Spam-Level: X-Spam-Status: No, score=-101.621 tagged_above=-999 required=5 tests=[AWL=0.978, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qyYd5-T1raE for ; Fri, 29 Apr 2011 09:31:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE4AE069F for ; Fri, 29 Apr 2011 09:31:53 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3TGVqEh030606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 29 Apr 2011 09:31:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <4DBADB62.10603@KingsMountain.com> Date: Fri, 29 Apr 2011 09:31:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <49CE2605-F8A4-42BF-9F46-B841480EE6CD@vpnc.org> References: <4DBADB62.10603@KingsMountain.com> To: =JeffH X-Mailer: Apple Mail (2.1084) Cc: IETF Tools List Subject: Re: [Tools-discuss] RFC search engine X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 16:31:54 -0000 > "thou shalt provide a modicum of documentation when submitting a = hack, . . . Right. What we have is already documented internally in the Python and a = bit more in the settings file. What we want to have before releasing = beyond the tools team is an external text file that describes the tools = and better commenting inside the Python so that other will feel = encouraged to add more to the code. --Paul Hoffman From paul.hoffman@vpnc.org Fri Apr 29 15:47:52 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75708E06AF for ; Fri, 29 Apr 2011 15:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.682 X-Spam-Level: X-Spam-Status: No, score=-101.682 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GENLVTMFQe8k for ; Fri, 29 Apr 2011 15:47:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B2172E0698 for ; Fri, 29 Apr 2011 15:47:51 -0700 (PDT) Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3TMllYn042912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Apr 2011 15:47:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Apr 2011 15:47:47 -0700 Message-Id: <095A3160-6C0A-4055-A55F-6FBDCD8FDB90@vpnc.org> To: Tools Team Discussion Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Tools-discuss] Bug in id-nits if a draft has an "Updates" header that lists a draft X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 22:47:52 -0000 Greetings again. I just tried to turn in a draft for = draft-ietf-genarea-milestones-tool that updates = draft-ietf-genarea-charter-tool-09 (a draft that is in the RFC Editor's = queue". My XML input used: id-nits would not accept that, I assume because it was looking for the = first string in the document that looked like an Internet-Draft name. I = was able to submit by removing the "updates" header, but I strongly = suspect that people will bug me about the fact that the draft internally = says that it updates this RFC-to-be but that is not listed in the front = page header. --Paul Hoffman From jmh@joelhalpern.com Sat Apr 30 16:41:25 2011 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97832E0713 for ; Sat, 30 Apr 2011 16:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28+JnA6poBan for ; Sat, 30 Apr 2011 16:41:25 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9F8E06FE for ; Sat, 30 Apr 2011 16:41:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 2BDC84300D8 for ; Sat, 30 Apr 2011 16:41:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-76.clppva.btas.verizon.net [71.161.52.76]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id B305A4300BD for ; Sat, 30 Apr 2011 16:41:24 -0700 (PDT) Message-ID: <4DBC9E23.5080808@joelhalpern.com> Date: Sat, 30 Apr 2011 19:41:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: tools-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Tools-discuss] XML2RFC tool, my confusion X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 23:41:25 -0000 I am not sure who one is supposed to ask when one gets inexplicable errors from xml2rfc. Sine we have been warned that strict conformance will be necessary, I try to use the tool on the strict setting. I am getting: Unable to Validate File INPUT: 330 ms (332 elems, 250 attrs, 1917 spaces, 38994 chars) [Error] INPUT:102:11: The content of element type "t" must match "(list|figure|xref|eref|iref|cref|spanx|vspace)". [Error] INPUT:665:15: The content of element type "section" must match "((t|figure|texttable|iref)*,section*)". I presume that this is complaining about an opening at line 102 and an opening

at line 665. The odd thing is that in each case, the tag in question immediately follows and end-tag of the same type. I have also tried assuming that the problem was the preceding paired tag. But the preceding start also immediately follows an end of the same type. I have tried opening the xml in Firefox, and it seems quite happy with the matching of tags. Suggestions on how I diagnose this would be appreciated. Yours, Joel M. Halpern PS: Yes, everything seems to work fine if I turn off strict checking.