From nemo-bounces@ietf.org Tue Jan 03 12:16:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etplo-00028r-8J; Tue, 03 Jan 2006 12:16:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Etpll-00028I-3S for nemo@megatron.ietf.org; Tue, 03 Jan 2006 12:16:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25257 for ; Tue, 3 Jan 2006 12:15:06 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Etpr3-0002zi-OF for nemo@ietf.org; Tue, 03 Jan 2006 12:21:51 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k03HQuof012164; Tue, 3 Jan 2006 10:26:56 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k03HPnOR026920; Tue, 3 Jan 2006 11:25:50 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E22A3865980; Tue, 3 Jan 2006 18:16:04 +0100 (CET) Message-ID: <43BAB154.30705@motorola.com> Date: Tue, 03 Jan 2006 18:16:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: rs1_22c0391591b, rs2_349b8913e3d, rs3_148101cb63 MIME-Version: 1.0 To: Takaaki Moriya Subject: Re: [nemo] Home address of mobile router References: <20051228175147.0E8E.MORIYA.TAKAAKI@lab.ntt.co.jp> In-Reply-To: <20051228175147.0E8E.MORIYA.TAKAAKI@lab.ntt.co.jp> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Takaaki Moriya wrote: > Hi all, > > > I have a question concerning home address of mobile router. > What RFC3963 (especially section 6.2) means is as follows ? > > > Home address of mobile router can be > A) configured with its ingress interface > B) configured with its egress interface > > and then, mobile router supports either A) or B) for home registration > and any other functions, while home agent must support both A) and B). I am not sure exactly what is the question... The intention in the document is to leave open the possibility of MR to configure its Home Address derived either from the egress interface or from the ingress interface. The document tries to not forbid deriving the Home Address from the ingress, and not from the egress either. However, it is clear that the Home Address should be derived only from one of the interfaces (it can't be derived from both at the same time). What is the doubt about HA supporting both ingress- and egress-derived MR Home Address style, and the MR supporting only one? In implementation, I prefer and recommend only the the Home Address derived from the egress interface home prefix (and no Home Address derived from the MNP). Other recommendations exist though. Alex From nemo-bounces@ietf.org Tue Jan 03 21:24:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtyKA-0005Ej-C4; Tue, 03 Jan 2006 21:24:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EtyK8-0005Ee-L4 for nemo@megatron.ietf.org; Tue, 03 Jan 2006 21:24:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21993 for ; Tue, 3 Jan 2006 21:23:11 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EtyPW-0002ee-NP for nemo@ietf.org; Tue, 03 Jan 2006 21:29:59 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k042OLT9014541; Wed, 4 Jan 2006 11:24:21 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k042OL9U002027; Wed, 4 Jan 2006 11:24:21 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k042OK9m009702; Wed, 4 Jan 2006 11:24:20 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k042OKAP012071; Wed, 4 Jan 2006 11:24:20 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k042OJI7009664; Wed, 4 Jan 2006 11:24:19 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (imj.m.ecl.ntt.co.jp [129.60.5.234]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k042OJ4G009659; Wed, 4 Jan 2006 11:24:19 +0900 (JST) Received: from [129.60.10.37] ([129.60.10.37]) by imj.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k042OB1C005700; Wed, 4 Jan 2006 11:24:18 +0900 (JST) Date: Wed, 04 Jan 2006 11:24:21 +0900 From: Takaaki Moriya To: Alexandru Petrescu Subject: Re: [nemo] Home address of mobile router In-Reply-To: <43BAB154.30705@motorola.com> References: <20051228175147.0E8E.MORIYA.TAKAAKI@lab.ntt.co.jp> <43BAB154.30705@motorola.com> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.054 Message-Id: <20060104112338.9BC9.MORIYA.TAKAAKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: IETF NEMO WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hello Alexandru, Thank you very much. Yes, my question supposes the Home Address derived only from one of the interfaces at the same time. So there are three cases: Implementation 1) a mobile router configured with its Home Address derived from the egress interface at any time Implementation 2) a mobile router configured with its Home Address derived from the ingress interface at any time Implementation 3) a mobile router which can be configured with its Home Address derived from the egress interface at one time, and from the ingress interface at another time So my question about MR is that the RFC does not permits only one of the above cases, but it permits all the above cases. > The intention in the document is to leave open the possibility of MR to > configure its Home Address derived either from the egress interface or > from the ingress interface. The document tries to not forbid deriving > the Home Address from the ingress, and not from the egress either. Yes, this comment seems to solve my question about MR :-) Meanwhile, my doubt about HA is that every home agent must accept all the above cases of MRs ? I think that the rule of HA is more severe than that of MR. Best Regards, Takaaki Moriya On Tue, 03 Jan 2006 18:16:04 +0100 Alexandru Petrescu wrote: > Takaaki Moriya wrote: > > > Hi all, > > > > > > I have a question concerning home address of mobile router. > > What RFC3963 (especially section 6.2) means is as follows ? > > > > > > Home address of mobile router can be > > A) configured with its ingress interface > > B) configured with its egress interface > > > > and then, mobile router supports either A) or B) for home registration > > and any other functions, while home agent must support both A) and B). > > I am not sure exactly what is the question... > > The intention in the document is to leave open the possibility of MR to > configure its Home Address derived either from the egress interface or > from the ingress interface. The document tries to not forbid deriving > the Home Address from the ingress, and not from the egress either. > > However, it is clear that the Home Address should be derived only from > one of the interfaces (it can't be derived from both at the same time). > > What is the doubt about HA supporting both ingress- and egress-derived > MR Home Address style, and the MR supporting only one? > > In implementation, I prefer and recommend only the the Home Address > derived from the egress interface home prefix (and no Home Address > derived from the MNP). Other recommendations exist though. > > Alex > -- Takaaki Moriya From nemo-bounces@ietf.org Mon Jan 16 19:48:58 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyf1u-0004rq-Ga; Mon, 16 Jan 2006 19:48:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyf1t-0004rl-C9 for nemo@megatron.ietf.org; Mon, 16 Jan 2006 19:48:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29609 for ; Mon, 16 Jan 2006 19:47:32 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyf9p-0003gm-3B for nemo@ietf.org; Mon, 16 Jan 2006 19:57:15 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id B75D98AB9B2 for ; Mon, 16 Jan 2006 16:47:50 -0800 (PST) Received: from multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23762-14 for ; Mon, 16 Jan 2006 16:47:50 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 175948AB98D; Mon, 16 Jan 2006 16:47:50 -0800 (PST) X-Spam-Score: -3.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on deimos.multihop.net X-Spam-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [192.103.16.119] (unknown [192.103.16.119]) by deimos.multihop.net (Postfix) with ESMTP id 426E58AB9A6 for ; Mon, 16 Jan 2006 16:47:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <252C2C36-1AFB-4B58-8694-49E59DBCA31B@kniveton.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ml-nemo WG From: "T.J. Kniveton" Date: Mon, 16 Jan 2006 16:48:16 -0800 X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [nemo] web site back up.. X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi folks, You may have noticed that the NEMO mobilenetworks.org web site was down. I just got back from vacation, and while I was away there was some construction and they decided to pull out all our cat5 and fiber optic connections. Anyway, it's sorted out now so things should be back to normal. TJ From nemo-bounces@ietf.org Tue Jan 17 04:40:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EynKI-0006ZM-4R; Tue, 17 Jan 2006 04:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EynKG-0006Yo-3H for nemo@megatron.ietf.org; Tue, 17 Jan 2006 04:40:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00194 for ; Tue, 17 Jan 2006 04:39:03 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EynSL-0006Ts-33 for nemo@ietf.org; Tue, 17 Jan 2006 04:48:50 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 17 Jan 2006 10:40:15 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0H9e55o028776; Tue, 17 Jan 2006 10:40:12 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Jan 2006 10:40:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C61B4A.019F4101" Date: Tue, 17 Jan 2006 10:40:03 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01B0ABA4@xmb-ams-337.emea.cisco.com> Thread-Topic: Home Network models update Thread-Index: AcYbSf48LAx3Y22ITeaC9crz31JQjA== From: "Pascal Thubert \(pthubert\)" To: X-OriginalArrivalTime: 17 Jan 2006 09:40:09.0723 (UTC) FILETIME=[01BB74B0:01C61B4A] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6fec066ffaeb98879e76835988c35b71 Cc: hardie@qualcomm.com, Pekka Savola , Margaret Wasserman Subject: [nemo] Home Network models update X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C61B4A.019F4101 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi:=20 =20 Margaret sent us the IESG review for the Home net model draft. Please = see inline: =20 =20 -------------------------------------------------------------------------= -------------- =20 Ted Hardie: Discuss: [2005-11-29] In 6.4.1, the document says: =20 Thus, on the Home Link, the Home Agent must intercept all the packets to ALL the Mobile Network Nodes on the registered prefixes. In order to do so, the Home Agent might perform some form of ND proxying for all addresses in all registered Mobile Network Prefixes. The Home Agent must also protect the MNP space from autoconfiguration by uncontrolled visitors at Neighbor Discovery level. =20 Alternatives based on a routing protocol or ICMP redirect may apply in some cases. =20 The second paragraph is not clear to me. Is the intent to say that ICMP = redirect or some routing=20 protocol behavior will substitute for ND proxying? =20 =20 Pascal: MADE THAT ISSUE 9 ------------------------- We'll make a separate discussion for it. =20 -------------------------------------------------------------------------= -------------- =20 =20 =20 =20 Comment: [2005-11-29] The document uses this example: =20 "Cab Co is a taxi Company that owns a /32 prefix" =20 The phrase "owns a /NN prefix" might be better put as "uses". The = question of ownership and address=20 prefixes has been the subject of non-technical debate over the years, = and skipping it might make=20 sense. =20 Pascal: OK ---------- =20 =20 -------------------------------------------------------------------------= -------------- =20 Scott Hollenbeck: Comment: [2005-11-29] The citation "[8]" should be removed from the Abstract and = the technical summary portion=20 of the ballot write-up. =20 Pascal: OK ---------- =20 =20 -------------------------------------------------------------------------= -------------- =20 David Kessens: Comment: [2005-11-30] Comments from the Ops directorate by Pekka Savola: =20 I found this document reasonably clear. I do not think there are any = blocking issues, but there seem=20 to be suitably many editorial clarifications that could help. As the = doc has normative refs to work=20 that is still at WG, there should be time to revise it. =20 semi-editorial issues --------------------- =20 =20 If the Mobile Router returns Home by Egress, a specific support is required to control the bridging operation depending on whether a Mobile Router is at Home or not. This support might not be present in all implementations. =20 =3D=3D> in a number of places you say "present in ... implementations" = .. but what about the specifications? Do specifications provide with = sufficient mechanisms to convey=20 which mechanism should be used by mobile routers in each of the = scenarios so that they would pick an=20 interoperable and/or working approach? (As I haven't studied the specs = in detail, I don't know the=20 answer -- this is just something that was not apparent from reading the = doc.) =20 =20 Pascal: Made that issue 10 -------------------------- We'll make a separate discussion for it. =20 =20 =20 =20 -------------------------------------------------------------------------= -------------- =20 =20 13.1 normative reference ... [9] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work in progress), February 2005. =20 [10] Ernst, T., "Network Mobility Support Goals and Requirements", draft-ietf-nemo-requirements-04 (work in progress), February 2005. =20 =3D=3D> these two are normative references but are still at WG. The = publication of this document will be=20 blocked until these are published as well... I hope the WG is aware of = this. =20 =20 Pascal: Thierry says it's OK, he will submit soon to IESG. ----------------------------------------------------------- =20 =20 =20 -------------------------------------------------------------------------= -------------- =20 =20 =20 =20 editorial --------- =20 =3D=3D> examples used the prefixes A:B:C::/48 and CAB:C0::/32. You = should use 2001:db8::/32 instead as=20 it's specifically meant as a doc prefix -- unless you have strong = reasons for otherwise. =20 =20 Pascal: it was supposed to help the user understand it's Cab Co. Is that = a big problem? -------------------------------------------------------------------------= -------------- =20 =20 =20 -------------------------------------------------------------------------= -------------- =20 =3D=3D> a number of terms weren't spelled out, such as MNP, MNN, ... =20 =20 Pascal: OK ---------- =20 =20 -------------------------------------------------------------------------= -------------- =20 =20 Abstract =20 This paper documents some usage patterns and the associated issues when deploying a Home Network for NEMO-enabled Mobile Routers, conforming the NEMO Basic Support draft [8]. =20 =3D=3D> no refs in the abstract. Don't use the word, "draft" especially = if it's an RFC ;-). =20 =20 Pascal: OK ---------- =20 =20 -------------------------------------------------------------------------= -------------- =20 The following terms used in this document are defined in the IPv6 Addressing Architecture document [5]: =20 link-local unicast address =20 link-local scope multicast address =20 =3D=3D> these terms are in fact not used in this doc, so this can be = removed. =20 =20 Pascal: OK ---------- =20 =20 -------------------------------------------------------------------------= -------------- =20 =20 6.2 [Aggregated Home Network - Returning home] ... Since the Home Network prefix is an aggregation that encompasses all the MNPs, the Home Address that an MR forms from one of its Mobile Network Prefixes will actually match both the Home Network prefix and its Mobile Network prefix. To properly identify the Home Network, the MR must expect a shorter prefix than that of the Mobile Network from which the Home Address was formed. =20 When the Mobile Router forms its Home Address out of one of its Mobile Network Prefixes, since the Home Network prefix is an aggregation that encompasses all the MNPs, the Home Address actually matches both prefixes. As a result, the MR must expect a shorter prefix than that of the Mobile Network from which the Home Address was formed. =20 =3D=3D> Isn't the 2nd paragraph baiscally text duplication of the first, = or was there a separate point=20 there? I had hard time following this. In any case, I'd suggest = rewording. =20 =20 Pascal: Oups, this is actually a leftover after a rewording of that = sentence -------------------------------------------------------------------------= --- this sentence has been reworked a number of time. I'll try a limited = update: =20 When the Mobile Router forms its Home Address out of one of its MNPs, since the Home Network prefix is an aggregation that = encompasses all the MNPs, the Home Address actually matches both prefixes. To properly identify the Home Network as it returns Home, = the MR must expect a shorter prefix length than that of the MNP = from which the Home Address was formed. =20 -------------------------------------------------------------------------= -------------- =20 =20 =20 Please refer to the NEMO multihoming issues [13] draft for more on this. =20 =3D=3D remove or reword "draft" =20 Pascal: OK ---------- =20 =20 -------------------------------------------------------------------------= -------------- =20 One should check with the product specifications of an Home Agent to see whether the implementation actually supports a Virtual Home Network, and if so, whether in that cases, it is optimized for faster DAD-less bindings. =20 =3D=3D> remove "with". Is the present wording even good for an IETF = doc? =20 Pascal: changed to a mere: -------------------------- Note that NEMO basic does not mandate the support of Virtual Home = Networks. =20 =20 =20 Thanks a lot to all reviewers :-) =20 =20 =20 =20 Pascal Thubert software engineer=20 Cisco Systems Village d'Entreprises GREEN SIDE 400, Avenue Roumanille B=E2timent T3 06410 BIOT - Sophia-Antipolis=20 pthubert@cisco.com =20 tel:=20 mobile:=20 +33 4 97 23 26 34 +33 6 19 98 29 85=20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C61B4A.019F4101 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi:

 

Margaret sent us the IESG review for the Home net = model draft. Please see inline:

 

 

------------------------------------------------------= ---------------------------------

 

Ted Hardie:

Discuss:

[2005-11-29] In 6.4.1, the document = says:

 

=A0 Thus, on the Home Link, the Home Agent must = intercept all the packets

=A0 to ALL the Mobile Network Nodes on the registered prefixes.=A0 In order

=A0 to do so, the Home Agent might perform some form = of ND proxying for

=A0 all addresses in all registered Mobile Network = Prefixes.=A0 The Home

=A0 Agent must also protect the MNP space from autoconfiguration by

=A0 uncontrolled visitors at Neighbor Discovery = level.

 

=A0 Alternatives based on a routing protocol or ICMP = redirect may apply

=A0 in some cases.

 

The second paragraph is not clear to me.=A0 Is the = intent to say that ICMP redirect or some routing

protocol behavior will substitute for ND = proxying?

 

 

Pascal: MADE THAT ISSUE = 9

-------------------------

=

We’ll make a separate discussion for = it.

 

------------------------------------------------------= ---------------------------------

 

 

 

 

Comment:

[2005-11-29] The document uses this = example:

 

"Cab Co is a taxi Company that owns a /32 = prefix"

 

The phrase "owns a /NN prefix" might be = better put as "uses".=A0 The question of ownership and address =

prefixes has been the subject of non-technical debate = over the years, and skipping it might make

sense.

 

Pascal: OK

----------

 

 

------------------------------------------------------= ---------------------------------

 

Scott Hollenbeck:

Comment:

[2005-11-29] The citation "[8]" should be = removed from the Abstract and the technical summary portion =

of the ballot write-up.

 

Pascal: OK

----------

 

 

------------------------------------------------------= ---------------------------------

 

David Kessens:

Comment:

[2005-11-30] Comments from the Ops directorate by = Pekka Savola:

 

I found this document reasonably clear.=A0 I do not = think there are any blocking issues, but there seem =

to be suitably many editorial clarifications that = could help.=A0 As the doc has normative refs to work =

that is still at WG, there should be time to revise = it.

 

semi-editorial issues

---------------------

 

 

=A0 If the Mobile Router returns Home by Egress, a = specific support is

=A0 required to control the bridging operation = depending on whether a

=A0 Mobile Router is at Home or not.=A0 This support = might not be present

=A0 in all = implementations.

 

=3D=3D> in a number of places you say = "present in ... implementations" ..

but what about the specifications?=A0 Do = specifications provide with sufficient mechanisms to convey =

which mechanism should be used by mobile routers in = each of the scenarios so that they would pick an

interoperable and/or working approach?=A0 (As I = haven't studied the specs in detail, I don't know the =

answer -- this is just something that was not = apparent from reading the doc.)

 

 

Pascal: Made that issue = 10

--------------------------

We’ll make a separate discussion for = it.

 

 

 

 

------------------------------------------------------= ---------------------------------

 

 

13.1=A0 normative = reference

...

=A0 [9]=A0 Ernst, T. and H. Lach, "Network = Mobility Support Terminology",

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-nemo-terminology-03 = (work in progress),

=A0=A0=A0=A0=A0=A0=A0 February = 2005.

 

=A0 [10]=A0 Ernst, T., "Network Mobility Support = Goals and Requirements",

=A0=A0=A0=A0=A0=A0=A0 draft-ietf-nemo-requirements-04 = (work in progress),

=A0=A0=A0=A0=A0=A0=A0 February = 2005.

 

=3D=3D> these two are normative references but are = still at WG.=A0 The publication of this document will be =

blocked until these are published as well... I hope = the WG is aware of this.

 

 

Pascal: Thierry says it's OK, he will submit soon to = IESG.

------------------------------------------------------= -----

 

 

 

------------------------------------------------------= ---------------------------------

 

 

 

 

editorial

---------

 

=3D=3D> examples used the prefixes A:B:C::/48 and CAB:C0::/32.=A0 You should use 2001:db8::/32 instead as =

it's specifically meant as a doc prefix -- unless you = have strong reasons for otherwise.

 

 

Pascal: it was supposed to help the user understand = it's Cab Co. Is that a big problem?

------------------------------------------------------= ---------------------------------

 

 

 

------------------------------------------------------= ---------------------------------

 

=3D=3D> a number of terms weren't spelled out, = such as MNP, MNN, ...

 

 

Pascal: OK

----------

 

 

------------------------------------------------------= ---------------------------------

 

 

Abstract

 

=A0 This paper documents some usage patterns and the associated issues

=A0 when deploying a Home Network for NEMO-enabled = Mobile Routers,

=A0 conforming the NEMO Basic Support draft = [8].

 

=3D=3D> no refs in the abstract.=A0 Don't use the = word, "draft" especially if it's an RFC = ;-).

 

 

Pascal: OK

----------

 

 

------------------------------------------------------= ---------------------------------

 

=A0 The following terms used in this document are = defined in the IPv6

=A0 Addressing Architecture document = [5]:

 

=A0=A0=A0=A0=A0 link-local unicast = address

 

=A0=A0=A0=A0=A0 link-local scope multicast = address

 

=3D=3D> these terms are in fact not used in this = doc, so this can be removed.

 

 

Pascal: OK

----------

 

 

------------------------------------------------------= ---------------------------------

 

 

6.2 [Aggregated Home Network - Returning home] = ...

=A0 Since the Home Network prefix is an aggregation = that encompasses all

=A0 the MNPs, the Home Address that an MR forms from = one of its Mobile

=A0 Network Prefixes will actually match both the = Home Network prefix and

=A0 its Mobile Network prefix.=A0 To properly = identify the Home Network,

=A0 the MR must expect a shorter prefix than that of = the Mobile Network

=A0 from which the Home Address was = formed.

 

=A0 When the Mobile Router forms its Home Address out = of one of its

=A0 Mobile Network Prefixes, since the Home Network = prefix is an

=A0 aggregation that encompasses all the MNPs, the = Home Address actually

=A0 matches both prefixes.=A0 As a result, the MR = must expect a shorter

=A0 prefix than that of the Mobile Network from which = the Home Address

=A0 was formed.

 

=3D=3D> Isn't the 2nd paragraph baiscally text = duplication of the first, or was there a separate point

there?=A0 I had hard time following this.=A0 In any = case, I'd suggest rewording.

 

 

Pascal: Oups, this is actually a leftover after a = rewording of that sentence

------------------------------------------------------= ----------------------

this sentence has been reworked a number of time. = I'll try a limited update:

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 When the Mobile Router

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 forms its Home = Address out of one of its MNPs,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 since the Home = Network prefix is an aggregation that encompasses all

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the MNPs, the Home = Address actually matches both prefixes.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 To properly = identify the Home Network as it returns Home, the MR

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 must expect a = shorter prefix length than that of the MNP from

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 which the Home = Address was formed.

 

------------------------------------------------------= ---------------------------------

 

 

 

Please

=A0 refer to the NEMO multihoming issues [13] draft = for more on this.

 

=3D=3D remove or reword = "draft"

 

Pascal: OK

----------

 

 

------------------------------------------------------= ---------------------------------

 

=A0 One should check with the product specifications = of an Home Agent to

=A0 see whether the implementation actually supports = a Virtual Home

=A0 Network, and if so, whether in that cases, it is = optimized for faster

=A0 DAD-less bindings.

 

=3D=3D> remove "with".=A0 Is the present = wording even good for an IETF doc?

 

Pascal: changed to a = mere:

--------------------------

Note that NEMO basic does not mandate the support of = Virtual Home Networks.

 

 

 

Thanks a lot to all reviewers J

 

 

 

 

Pascal Thubert
software = engineer

Cisco = Systems
Village d'Entreprises GREEN SIDE
400, Avenue Roumanille
B=E2timent T3
06410 BIOT - Sophia-Antipolis

pthubert@cisco.com

tel:
mobile:

+33 4 97 23 26 34
+33 6 19 98 29 85

 

 

 

 

 

------_=_NextPart_001_01C61B4A.019F4101-- From nemo-bounces@ietf.org Tue Jan 17 05:16:33 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyntB-0002Ie-D7; Tue, 17 Jan 2006 05:16:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eynt9-0002G6-Ip for nemo@megatron.ietf.org; Tue, 17 Jan 2006 05:16:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02241 for ; Tue, 17 Jan 2006 05:15:07 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eyo1F-0007u2-1n for nemo@ietf.org; Tue, 17 Jan 2006 05:24:54 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0HAFMYG002759; Tue, 17 Jan 2006 12:15:22 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0HAFMVf002756; Tue, 17 Jan 2006 12:15:22 +0200 Date: Tue, 17 Jan 2006 12:15:22 +0200 (EET) From: Pekka Savola To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01B0ABA4@xmb-ams-337.emea.cisco.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC01B0ABA4@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1243/Sun Jan 15 20:35:18 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nemo@ietf.org, Margaret Wasserman Subject: [nemo] Re: Home Network models update X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Tue, 17 Jan 2006, Pascal Thubert (pthubert) wrote: > editorial > --------- > > ==> examples used the prefixes A:B:C::/48 and CAB:C0::/32. You should use 2001:db8::/32 instead as > it's specifically meant as a doc prefix -- unless you have strong reasons for otherwise. > > Pascal: it was supposed to help the user understand it's Cab Co. Is that a big problem? The document needs to justify why it uses those if that's what you wish to do. In this particular case, I see the "CAB:C0::/32" prefix used only under section 8, where you don't use any other prefixes, so I think using 2001:DB8::/32 shouldn't cause confusion here. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nemo-bounces@ietf.org Thu Jan 19 02:54:26 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzUck-0003uj-Hg; Thu, 19 Jan 2006 02:54:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzUcg-0003r6-Bi for nemo@megatron.ietf.org; Thu, 19 Jan 2006 02:54:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28351 for ; Thu, 19 Jan 2006 02:52:56 -0500 (EST) Received: from tama55.ecl.ntt.co.jp ([129.60.39.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzUl9-0004gx-58 for nemo@ietf.org; Thu, 19 Jan 2006 03:03:09 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama55.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k0J7sH8e009669 for ; Thu, 19 Jan 2006 16:54:17 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k0J7sF05024323 for ; Thu, 19 Jan 2006 16:54:15 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k0J7sEDr005553 for ; Thu, 19 Jan 2006 16:54:14 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k0J7sEn6013018 for ; Thu, 19 Jan 2006 16:54:14 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k0J7sDl4000686 for ; Thu, 19 Jan 2006 16:54:13 +0900 (JST) Received: from imj.m.ecl.ntt.co.jp (imj.m.ecl.ntt.co.jp [129.60.5.234]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k0J7sDwK000682 for ; Thu, 19 Jan 2006 16:54:13 +0900 (JST) Received: from [129.60.10.37] ([129.60.10.37]) by imj.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k0J7sDrX004852 for ; Thu, 19 Jan 2006 16:54:13 +0900 (JST) Date: Thu, 19 Jan 2006 16:54:17 +0900 From: Takaaki Moriya To: nemo@ietf.org Subject: Re: [nemo] IPsec for payload packets In-Reply-To: <200512311059.jBVAx9qw054332@givry.rennes.enst-bretagne.fr> References: <20051227191919.F54E.MORIYA.TAKAAKI@lab.ntt.co.jp> <200512311059.jBVAx9qw054332@givry.rennes.enst-bretagne.fr> X-Mailer-Plugin: BkASPil for Becky!2 Ver.2.054 Message-Id: <20060119162400.BB64.MORIYA.TAKAAKI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.24.02 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi all, I'm sorry for bringing up this issue again. I work for TAHI project, and I would like some predetermined policies/entries when conducting conformance and interoperability tests. Therefore, we are now preparing NEMO interoperability test scenario including the additional "SA9 and SA10" policies which I mentioned. We consider that these policies shuold be recommended for interoperability tests. I would appreciate your informing us of any comments or advices you may have. Thank you very much in advance. On Sat, 31 Dec 2005 11:59:09 +0100 Francis Dupont wrote: > In your previous mail you wrote: > > I understand what you mean, but I have been considering this issue from > the viewpoint of interoperability. > > => the answer is simple: the policies (I use this term because the formal > SPD entries don't include common things like SA sharing control) must > match or something will fail. So when there are possible choices (and > when you consider SA sharing issues there are likely some) one must > take care to configure compatible policies... > > I mean, since RFC3963 just refers to RFC3776 regarding IPsec, I wonder > whether all the developers can expect the same (or equivalent) SPD > entries. > > => no but all the developers should propose enough or it will be possible > to find no compatible policies... > > Regards > > Francis.Dupont@point6.net -- Takaaki Moriya From nemo-bounces@ietf.org Thu Jan 19 05:23:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWx0-0000yC-4j; Thu, 19 Jan 2006 05:23:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWwy-0000y7-PH for nemo@megatron.ietf.org; Thu, 19 Jan 2006 05:23:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08922 for ; Thu, 19 Jan 2006 05:22:01 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzX5T-0001Fj-Np for nemo@ietf.org; Thu, 19 Jan 2006 05:32:17 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2006 11:23:18 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0JALI6G003716; Thu, 19 Jan 2006 11:23:15 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jan 2006 11:22:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jan 2006 11:22:58 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01B4FD23@xmb-ams-337.emea.cisco.com> Thread-Topic: Home network model issue 10 Thread-Index: AcYc3e3btelia0OvSSKU+QRDclWbVg== From: "Pascal Thubert \(pthubert\)" To: , "Pekka Savola" X-OriginalArrivalTime: 19 Jan 2006 10:22:59.0034 (UTC) FILETIME=[51FCB3A0:01C61CE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: Subject: [nemo] Home network model issue 10 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org ------------------------------------------------------------------------ ---- Pekka ------------------------------------------------------------------------ ---- " If the Mobile Router returns Home by Egress, a specific support is required to control the bridging operation depending on whether a Mobile Router is at Home or not. This support might not be present in all implementations." =3D=3D> in a number of places you say "present in ... implementations" = .. but what about the specifications? Do specifications provide with sufficient mechanisms to convey which mechanism should be used by mobile routers in each of the scenarios so that they would pick an interoperable and/or working approach? (As I haven't studied the specs in detail, I don't know the answer -- this is just something that was not apparent from reading the doc.) ------------------------------------------------------------------------ ---- Pascal ------------------------------------------------------------------------ ---- Proposed change:=20 instead of "present in ... implementations" (which appears twice) in the routing section: "The NEMO Basic Support does not mandate a specific routing protocol though the support for some well known routing protocols can be expected from many implementations. An implementation might provide an automatic toggle to start/stop routing on an egress interface when the mobile router comes back/leaves Home. When such a toggle is unavailable, then a specific interface should be reserved to attach to Home with the appropriate settings for security and routing." in the bridging section: " The NEMO Basic Support does not mention a specific behavior for bridging=20 though Bridging capabilities can be expected from many implementations.=20 An implementation might provide an automatic toggle to start/stop bridging on an egress interface when the mobile router comes back/leaves Home.=20 When such a toggle is unavailable, then a specific interface should be reserved to attach to Home with the appropriate settings for security and bridging." Comments? Pascal From nemo-bounces@ietf.org Thu Jan 19 05:23:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWx2-0000yj-LO; Thu, 19 Jan 2006 05:23:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzWx1-0000yb-GH for nemo@megatron.ietf.org; Thu, 19 Jan 2006 05:23:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08925 for ; Thu, 19 Jan 2006 05:22:04 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzX5V-0001Fj-DR for nemo@ietf.org; Thu, 19 Jan 2006 05:32:19 -0500 Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 19 Jan 2006 11:23:19 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0JAMr66004182; Thu, 19 Jan 2006 11:23:16 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 19 Jan 2006 11:22:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jan 2006 11:22:51 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC01B4FD24@xmb-ams-337.emea.cisco.com> Thread-Topic: Home Network models update Thread-Index: AcYbTvJsM5H41shoR9+Ruf1Oiso/OgBkjhgA From: "Pascal Thubert \(pthubert\)" To: "Pekka Savola" X-OriginalArrivalTime: 19 Jan 2006 10:22:59.0362 (UTC) FILETIME=[522EC020:01C61CE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: nemo@ietf.org Subject: [nemo] RE: Home Network models update X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Hi Pekka: The Cab Co illustration is a bit hard to follow. Using cab:co::/32 actually helped people and I got positive comments on that in the past. I added the following sentence just above the drawing: "To illustrate this configuration, we make up the prefixes to reflect their role, like CAB:C0::/32 for the Home Network:" So section 8 looks like this now: 8.1 Configuration In this arrangement, there is a bitwise hierarchy of Home Networks. A global Home Network is advertised to the infrastructure by a head Home Agent(s) and further subnetted into Mobile Networks. As a result, only the Home Agent(s) responsible for the most global (shortest prefix) aggregation receive all the packets for all the MNPs, which are leaves in the hierarchy tree. Each subnet is owned by a Mobile Router that registers it in a NEMO fashion while acting as a Home Agent for that network This Mobile Router is at Home at the upper level of hierarchy. This configuration is referred to as Mobile Home. An example of this is the Cab Co configuration. Cab Co is a taxi Company that uses a /32 prefix for its Home Network, this prefix being advertised by the company Head Quarters. Regional offices are deployed around the coutry. Even though these regional offices are relatively stable in terms of location and prefix requirement -say this changes every few years- making them mobile allows a simpler management when a move has to take place, or should the ISP service change. To illustrate this configuration, we make up the prefixes to reflect their role, like CAB:C0::/32 for the Home Network: global Home Network CAB:C0::/32 advertised by HQ <------------------------------------------------------------------> HQ Extended Home Net Mobile Home for SFO office (casa) CAB:C0:CA5A::/48 CAB:C0:5F0::/48 <----------------------------> ... <-------------------------------> | Home for offices HQ | CAB:C0:CA5A:CA5A::/64 MN | <----------------------><----> | CAB:C0:CA5A:CA5A::CA5A | CAB:C0:CA5A:CA5A::CA5B | are HAs on link with for each office a route like | | CAB:C0:CA5A:CA5A::5F0 <---------------------- via is the Home addr of SFO office Figure 6: CAB Company HQ configuration Is that OK with you? Pascal >-----Original Message----- >From: Pekka Savola [mailto:pekkas@netcore.fi] >Sent: Tuesday, January 17, 2006 11:15 AM >To: Pascal Thubert (pthubert) >Cc: nemo@ietf.org; Margaret Wasserman >Subject: Re: Home Network models update > >On Tue, 17 Jan 2006, Pascal Thubert (pthubert) wrote: >> editorial >> --------- >> >> =3D=3D> examples used the prefixes A:B:C::/48 and CAB:C0::/32. You should use 2001:db8::/32 instead as >> it's specifically meant as a doc prefix -- unless you have strong reasons for otherwise. >> >> Pascal: it was supposed to help the user understand it's Cab Co. Is that a big problem? > >The document needs to justify why it uses those if that's what you >wish to do. > >In this particular case, I see the "CAB:C0::/32" prefix used only >under section 8, where you don't use any other prefixes, so I >think using 2001:DB8::/32 shouldn't cause confusion here. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nemo-bounces@ietf.org Thu Jan 19 07:12:17 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYeH-0001Eg-1k; Thu, 19 Jan 2006 07:12:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzYeG-0001Eb-Am for nemo@megatron.ietf.org; Thu, 19 Jan 2006 07:12:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15867 for ; Thu, 19 Jan 2006 07:10:50 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzYmk-0004W5-Nl for nemo@ietf.org; Thu, 19 Jan 2006 07:21:05 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0JCBqHa014043; Thu, 19 Jan 2006 14:11:52 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0JCBpdo014040; Thu, 19 Jan 2006 14:11:51 +0200 Date: Thu, 19 Jan 2006 14:11:51 +0200 (EET) From: Pekka Savola To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01B4FD24@xmb-ams-337.emea.cisco.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC01B4FD24@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1245/Wed Jan 18 18:57:44 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED,AWL autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: nemo@ietf.org Subject: [nemo] RE: Home Network models update X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 19 Jan 2006, Pascal Thubert (pthubert) wrote: > "To illustrate this configuration, we make up the prefixes to reflect > their role, like CAB:C0::/32 for the Home Network:" ... > Is that OK with you? OK. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nemo-bounces@ietf.org Thu Jan 19 09:55:03 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbBn-0000C7-Ra; Thu, 19 Jan 2006 09:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbBm-0000BM-44 for nemo@megatron.ietf.org; Thu, 19 Jan 2006 09:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28618 for ; Thu, 19 Jan 2006 09:53:35 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbKJ-0001v0-B2 for nemo@ietf.org; Thu, 19 Jan 2006 10:03:52 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k0JF5uP8010777; Thu, 19 Jan 2006 08:05:56 -0700 (MST) Received: from [144.189.72.207] (mvp-144-189-72-207.corp.mot.com [144.189.72.207]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k0JF3lg3029440; Thu, 19 Jan 2006 09:03:48 -0600 (CST) Message-ID: <43CFA74D.801@motorola.com> Date: Thu, 19 Jan 2006 15:50:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [nemo] RE: Home Network models update References: <7892795E1A87F04CADFCCF41FADD00FC01B4FD24@xmb-ams-337.emea.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pekka Savola wrote: > On Thu, 19 Jan 2006, Pascal Thubert (pthubert) wrote: >> "To illustrate this configuration, we make up the prefixes to >> reflect their role, like CAB:C0::/32 for the Home Network:" > ... >> Is that OK with you? > > OK. Sorry for interfering. I don't see why using Cab C0 instead of the recommended 2001:db8::/32. For one, Cab Co is easily confusable with Cab C0, because barred 0 looks so only with _some_ fonts. Fun hexa IPv6 prefixes exist all over the place in many other documents. DEAD::BEEF is another example. During the lifetime of an RFC it may be the case that both DEAD::BEEF and CAB::C0 will be allocated to some real deployments, at which point reading that RFC may be confusing. Is this RFC talking about _my_ deployment? Alex From nemo-bounces@ietf.org Thu Jan 19 09:59:49 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbGP-0002oA-Jo; Thu, 19 Jan 2006 09:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzbGO-0002o2-IN for nemo@megatron.ietf.org; Thu, 19 Jan 2006 09:59:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29086 for ; Thu, 19 Jan 2006 09:58:21 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzbOv-0002AO-W1 for nemo@ietf.org; Thu, 19 Jan 2006 10:08:39 -0500 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k0JFDtF2028307; Thu, 19 Jan 2006 08:13:55 -0700 (MST) Received: from [144.189.72.207] (mvp-144-189-72-207.corp.mot.com [144.189.72.207]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k0JF8Dni026659; Thu, 19 Jan 2006 09:08:16 -0600 (CST) Message-ID: <43CFA935.20809@motorola.com> Date: Thu, 19 Jan 2006 15:59:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pekka Savola Subject: Re: [nemo] RE: Home Network models update References: <7892795E1A87F04CADFCCF41FADD00FC01B4FD24@xmb-ams-337.emea.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Pekka Savola wrote: > On Thu, 19 Jan 2006, Pascal Thubert (pthubert) wrote: >> "To illustrate this configuration, we make up the prefixes to >> reflect their role, like CAB:C0::/32 for the Home Network:" > ... >> Is that OK with you? > > OK. > > -- Pekka Savola "You each name yourselves king, yet > the Netcore Oy kingdom bleeds." Systems. Networks. > Security. -- George R.R. Martin: A Clash of Kings > Otherwise maybe make example 2001:DB8:cabc:0::/56 and then refer it into the text as "the Cab Co prefix"? Alex From nemo-bounces@ietf.org Fri Jan 20 07:35:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvUQ-0006BL-Me; Fri, 20 Jan 2006 07:35:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvUO-0006B8-Ff for nemo@megatron.ietf.org; Fri, 20 Jan 2006 07:35:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09060 for ; Fri, 20 Jan 2006 07:34:09 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezvd6-0002ew-Mh for nemo@ietf.org; Fri, 20 Jan 2006 07:44:38 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0KCZHHa019767; Fri, 20 Jan 2006 14:35:17 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0KCZHg1019764; Fri, 20 Jan 2006 14:35:17 +0200 Date: Fri, 20 Jan 2006 14:35:17 +0200 (EET) From: Pekka Savola To: "Pascal Thubert (pthubert)" In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC01B4FD23@xmb-ams-337.emea.cisco.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC01B4FD23@xmb-ams-337.emea.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1246/Thu Jan 19 23:44:42 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nemo@ietf.org Subject: [nemo] Re: Home network model issue 10 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org If NEMO WG members are fine with this, I'm OK with it. On Thu, 19 Jan 2006, Pascal Thubert (pthubert) wrote: > " If the Mobile Router returns Home by Egress, a specific support is > required to control the bridging operation depending on whether a > Mobile Router is at Home or not. This support might not be present > in all implementations." > > ==> in a number of places you say "present in ... implementations" .. > but what about the specifications? Do specifications provide with > sufficient > mechanisms to convey which mechanism should be used by mobile routers in > each > of the scenarios so that they would pick an interoperable and/or working > approach? (As I haven't studied the specs in detail, I don't know the > answer > -- this is just something that was not apparent from reading the doc.) > > ------------------------------------------------------------------------ > ---- > Pascal > ------------------------------------------------------------------------ > ---- > Proposed change: > > instead of "present in ... implementations" (which appears twice) > > in the routing section: > > "The NEMO Basic Support does not mandate a specific routing protocol > though the support for some well known routing protocols can > be expected from many implementations. An implementation might provide > an automatic toggle to start/stop routing on an egress interface > when the mobile router comes back/leaves Home. When such a toggle is > unavailable, then a specific interface should be reserved to attach to > Home > with the appropriate settings for security and routing." > > in the bridging section: > > " The NEMO Basic Support does not mention a specific behavior for > bridging > though Bridging capabilities can be expected from many implementations. > An implementation might provide an automatic toggle to start/stop > bridging > on an egress interface when the mobile router comes back/leaves Home. > When such a toggle is unavailable, then a specific interface should be > reserved to attach to Home with the appropriate settings for security > and bridging." > > > Comments? > > Pascal > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From nemo-bounces@ietf.org Fri Jan 20 07:42:27 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezvb1-0001jU-Ia; Fri, 20 Jan 2006 07:42:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezvaz-0001hE-VE for nemo@megatron.ietf.org; Fri, 20 Jan 2006 07:42:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09562 for ; Fri, 20 Jan 2006 07:40:59 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ezvji-0002rk-BW for nemo@ietf.org; Fri, 20 Jan 2006 07:51:28 -0500 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0KCgAHa019904; Fri, 20 Jan 2006 14:42:10 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0KCgA9D019901; Fri, 20 Jan 2006 14:42:10 +0200 Date: Fri, 20 Jan 2006 14:42:10 +0200 (EET) From: Pekka Savola To: Alexandru Petrescu Subject: Re: [nemo] RE: Home Network models update In-Reply-To: <43CFA935.20809@motorola.com> Message-ID: References: <7892795E1A87F04CADFCCF41FADD00FC01B4FD24@xmb-ams-337.emea.cisco.com> <43CFA935.20809@motorola.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.87.1/1246/Thu Jan 19 23:44:42 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: nemo@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org On Thu, 19 Jan 2006, Alexandru Petrescu wrote: > Pekka Savola wrote: >> On Thu, 19 Jan 2006, Pascal Thubert (pthubert) wrote: >>> "To illustrate this configuration, we make up the prefixes to >>> reflect their role, like CAB:C0::/32 for the Home Network:" >> ... >>> Is that OK with you? >> >> OK. > > Otherwise maybe make example 2001:DB8:cabc:0::/56 and then refer it into > the text as "the Cab Co prefix"? Let me expand on my feelings on this. ID-Checklist makes it quite clear that other than 2001:DB8::/32 should not be used. But that is just a guideline, and there have been cases in the past (I've written one myself: see RFC 3964) where it has been reasonable to use other prefixes instead. In such cases, documenting the justification (and placing a warning) has been required. Personally, I'm not really convinced that using CAB:C0::/32 brings enough value (I don't think it can be confused because it's only used in one section of the document, and other prefixes aren't mentioned in that part of the document). But given that I don't think this issue is major and at least some reason has been proposed, I think this issue should be decided by the WG and the AD (Margaret). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings