RE: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Mark,

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Mark Smith
> Sent: Sunday, January 10, 2010 3:19 AM
> To: Mikael Abrahamsson
> Cc: IPv6 Operations
> Subject: Re: I-D Action:draft-ietf-v6ops-ipv6-cpe-router-03.txt
> 
> On Sun, 10 Jan 2010 11:48:06 +0100 (CET)
> Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> > On Sun, 10 Jan 2010, Mark Smith wrote:
> >
> > > My argument is that if an SP chooses to have the layer 2 edge
> > > device perform those security functions, then there is an opportunity
> > > for more optimal traffic forwarding via a mechanism like a
> > > prefix-redirect. You may not like that design, but you might not have
> > > to be making decisions about the tradeoffs between backhaul cost, capex
> > > and opex of aggregated-vs-per-POP layer 3 and the influence over
> > > customer density and geography that other SPs around the world have to
> > > make.
> >
> > Since some ISPs seem fine with backhauling their PPPoE traffic to a single
> > place in a whole nation, let's (as said in another mail) postpone these
> > hypothetical optimizations to a later update of the document. Right now we
> > need to get IPv6 out the door at all, and still do it securely. I'd rather
> > have the vendors implement the things we have in the document right now,
> > than adding more things in there and postponing deployment further.
> >
> 
> I agree, the draft shouldn't be held up. I wasn't ever saying that this
> prefix-redirect idea should be in this draft, only that CPE RAs towards
> the SP might be a place that such a supported capability could be
> announced, which of course wouldn't be possible if this draft stopped
> CPE from issuing RAs.
> 
> Thinking about it a bit further, I think a Neighbor Announcement option
> might be an alternative and possibly better place for this capability
> announcement option, should the idea itself have merit.

Use of the NA instead of RA would prevent the CE router
from advertising information that would conflict with
the information advertised by SP routers. I am thinking
here about link-related information such as Reachable
Time, Retrans Timer, and those confounded M&O bits that
occur in RA messages but not NA.

One matter of concern is whether we can use NA messages
for the purpose of SEND Authorization Delegation Discovery
per RFC3971, Section 6. By my read of that section, it says
that the authorization model is used to protect Router
Discovery but it does *not* say that only RA messages (and 
not NA) must be used. Hence, I presume that we can piggyback
RFC3971 section 6 authorization delegation discovery on top
of NA messages?

James Woodyatt's disclaimer notwithstanding, does anyone
see an issue with using unsolicited, unicast NAs?

Thanks - Fred
fred.l.templin@boeing.com

> Regards,
> Mark.
>