RE: Comments on IPv6 Prefix Subdelegation

"Azinger, Marla" <marla.azinger@frontiercorp.com> Wed, 29 July 2009 08:35 UTC

Return-Path: <marla.azinger@frontiercorp.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ABA83A6EE2 for <ipv6@core3.amsl.com>; Wed, 29 Jul 2009 01:35:29 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgu1DMt2CYJw for <ipv6@core3.amsl.com>; Wed, 29 Jul 2009 01:35:28 -0700 (PDT)
Received: from frontiercorp.com (mail01.frontiercorp.com [66.133.172.19]) by core3.amsl.com (Postfix) with ESMTP id 1E34D3A6E6C for <ipv6@ietf.org>; Wed, 29 Jul 2009 01:35:27 -0700 (PDT)
Received: from ([10.162.69.12]) by mail01.frontiercorp.com with ESMTP with TLS id 4440454.286562603; Wed, 29 Jul 2009 04:35:24 -0400
Received: from ROCH-EXCH1.corp.pvt ([10.160.69.50]) by NYROFCSWNEXHT03.corp.pvt ([10.162.69.12]) with mapi; Wed, 29 Jul 2009 04:35:05 -0400
From: "Azinger, Marla" <marla.azinger@frontiercorp.com>
To: Fred Baker <fred@cisco.com>
Date: Wed, 29 Jul 2009 04:35:03 -0400
Subject: RE: Comments on IPv6 Prefix Subdelegation
Thread-Topic: Comments on IPv6 Prefix Subdelegation
Thread-Index: AcoQCkd1FYzOBRjPRSajBzBlnmI+QwAHM3eg
Message-ID: <2E2FECEBAE57CC4BAACDE67638305F1048509A903E@ROCH-EXCH1.corp.pvt>
References: <6C2F751B-119F-41D6-878C-C4CFBD57DF14@cisco.com> <2E2FECEBAE57CC4BAACDE67638305F10485093E811@ROCH-EXCH1.corp.pvt> <A17AA367-2FC2-4EC8-A3B4-A7EAB1F0C1CC@cisco.com> <2E2FECEBAE57CC4BAACDE67638305F10485093E983@ROCH-EXCH1.corp.pvt> <74BEE319-C600-4DF5-B784-445B8CDEA770@cisco.com>
In-Reply-To: <74BEE319-C600-4DF5-B784-445B8CDEA770@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-esp: ESP<10>= SHA:<0> SHA_FLAGS:<0> UHA:<10> ISC:<0> BAYES:<0> SenderID:<0> DKIM:<0> TS:<0> SIG:<> DSC:<0> TRU_scam_spam: <0> TRU_html_image_spam: <0> TRU_urllinks: <0> TRU_spam2: <0> TRU_marketing_spam: <0> TRU_profanity_spam: <0> TRU_legal_spam: <0> TRU_stock_spam: <0> TRU_watch_spam: <0> TRU_money_spam: <0> TRU_ru_spamsubj: <0> TRU_embedded_image_spam: <0> TRU_phish_spam: <0> TRU_spam1: <0> TRU_lotto_spam: <0> TRU_medical_spam: <0> TRU_playsites: <0> TRU_freehosting: <0> TRU_adult_spam: <0> TRU_misc_spam: <0> URL Real-Time Signatures: <0>
Cc: "draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org" <draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org>, "draft-donley-ipv6-cpe-rtr-use-cases-and-reqs@tools.ietf.org" <draft-donley-ipv6-cpe-rtr-use-cases-and-reqs@tools.ietf.org>, IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2009 08:35:29 -0000

I think having some wording on it pertaining to the homes internal upstream might work.  I massaged the paragraph a little and included that clarification.  So what do you think of this:


Routing in such an environment calls for a routing protocol. Each CPE must run either RIPv6 [RFC2080], IS-IS [RFC5308], or OSPF [RFC5340] on a default route and to the homes interal upstream a static default route. The issues raised in [RFC3704] also apply, meaning that the two CPE routers may each need to observe the source addresses in datagrams  they handle to divert them to the other CPE to handle upstream 



-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com] 
Sent: Tuesday, July 28, 2009 10:06 PM
To: Azinger, Marla
Cc: IETF IPv6 Mailing List; draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org; draft-donley-ipv6-cpe-rtr-use-cases-and-reqs@tools.ietf.org
Subject: Re: Comments on IPv6 Prefix Subdelegation

Maybe you can help me reword it. What I am getting at is this:

a) within the home, in the example in figure 3, I have four routers and nine IP subnets. For each router to know where in the home to send data, the usual thing is for the routers in the home to do is communicate with the others using a routing protocol.

b) there are two CPE routers, each of which has an upstream router in its ISP. Since they are not exchanging a routing protocol with their upstream, they will need a static route in their own tables and to advertise a default upstream route within the home.

c) RFC 3704 observes on the ingress filtering performed in the upstream routers, and suggests that the two CPE routers should have some way to ensure that they only send traffic that will pass the filter to their upstream. Hence, each CPE Router might have a filter installed that looks at the source address of a datagram and when necessary forwards it to the other CPE. Or if we had source/ destination routing, could advertise the relevant prefix with its default route, so that the three routers (not CPE routers, just plain old routers, but probably with a firewall filter configured due to the observation about corporate information security policies applying to telecommuting home offices) would be able to send traffic to the right CPE.

How would you suggest I word this? In my mind, taking what is written there and confusing it with the relationship with the upstream ISP requires a strange reading of the text, which is all about routing within the home.

On Jul 28, 2009, at 3:51 PM, Azinger, Marla wrote:

>
> Fred:  Here is the paragraph that is worded in a way that leads me to 
> thinking you are saying to do OSPF to the upstream.  I believe 
> something needs to be taken out or added to clarify it:
>
> Routing in such an environment calls for a routing protocol such as
>   RIPv6 [RFC2080], IS-IS [RFC5308], or OSPF [RFC5340].  In addition,
>   each CPE router will need to install a static default route upstream
>   and advertise a default route in the chosen routing protocol.  The
>   issues raised in [RFC3704] also apply, meaning that the two CPE
>   routers may each need to observe the source addresses in datagrams
>   they handle to divert them to the other CPE to handle upstream
>
> -----Original Message-----
> From: Azinger, Marla
> Sent: Tuesday, July 28, 2009 4:25 AM
> To: 'Fred Baker'
> Cc: IETF IPv6 Mailing List; 
> draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org
> ; draft-donley-ipv6-cpe-rtr-use-cases-and-reqs@tools.ietf.org
> Subject: RE: Comments on IPv6 Prefix Subdelegation
>
> Im thinking one step further than the double routers.  For example if 
> these routers are not serviced by something at least the service
> type of a dedicated T1 to each router then they would be doing VPN.   
> So there are more requirements that need to be met here to make OSPF a 
> realistic option.
>
> Thank you
> Marla
>
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Tuesday, July 28, 2009 2:59 AM
> To: Azinger, Marla
> Cc: IETF IPv6 Mailing List; 
> draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org
> ; draft-donley-ipv6-cpe-rtr-use-cases-and-reqs@tools.ietf.org
> Subject: Re: Comments on IPv6 Prefix Subdelegation
>
>
> On Jul 28, 2009, at 11:39 AM, Azinger, Marla wrote:
>
>> 2.  I have concern regarding the suggestions in section 2.3   Am I
>> interpreting this correctly that you are suggesting upstreams do OSPF 
>> over VPN with residential customers?
>
> within their homes?
>
> No, I am suggesting that in a home that has more than one router, one 
> might want an IGP, just like one does in other places.