RE: Posted a new copy of CPE Rtr draft

["Dan Wing" <dwing@cisco.com>]

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of 
> teemu.savolainen@nokia.com
> Sent: Friday, March 20, 2009 10:14 AM
> To: shemant@cisco.com; v6ops@ops.ietf.org
> Cc: wbeebee@cisco.com
> Subject: RE: Posted a new copy of CPE Rtr draft
> 
> Thanks for quick reply, I was ok with other things than this one:
> 
> >- 7.1. In 3GPP case the /64 prefix is not only for LAN 
> >interfaces, but also for the WAN interface. Thus I'd rather 
> >say:".. across multiple LAN interfaces, possibly including WAN 
> >interfase as well, and the CPE router..". Then "..any two LAN 
> >interfaces.." -> "..any two interfaces..". And still later 
> >"..if any two disparate LAN interfaces..." -> "..if any two 
> >disparate interfaces..".
> >
> ><hs>
> >Disagree. You are suggesting one implement ND Proxy between 
> >the WAN and LAN interfaces.  For the CPE Rtr, the WAN and LAN 
> >interface(s) are two different routing domains - if one can 
> >perform routing between domains, why support ND Proxy?  We are 
> >also making the last sentence better in section 7.1 as follows:
> 
> Yes. That is what has to be done in the link types we have to 
> support. I don't see any other way when there is just single 
> /64 received from point-to-point WAN interface (in RA) which 
> has to be enough for numbering the "CPE" itself and all the 
> devices in Ethernet LAN behind. Please let me know if there 
> is a better way.
> 
> Only alternative I see is to have NAT66 in CPE similar to 
> IPv4 NAT we already have to share the single IPv4 address we 
> get from operator.

I feel compelled to point out that 
draft-mrw-behave-nat66-02.txt, "IPv6-to-IPv6 Network Address 
Translation (NAT66)" does not share IPv6 addresses.

-d

> It would be very nice if there would be DHCPv6 PD available 
> for "CPE" to ask for prefixes for LAN, but unfortunately that 
> is not always the case.
> 
> I think we discussed this in IETF#73 corridor, but I have 
> forgotten details... So maybe I should write a link-type 
> specific document, which would describe this behaviour (maybe 
> corner-case from IETF point of view, but the most important 
> use-case from my point of view)? After all, I guess it is 
> better to describe it rather than have it just as 
> implementation-specific design choice?
>
> Best regards,
> 
> 	Teemu (I will not be able to make the v6ops meeting as 
> I have to be in shara BOF)