[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Posted a new copy of CPE Rtr draft
Hmmm...
I wonder, would ULA's on the LAN side suffice? Or is this a zero-LAN
model?
- Wes
-----Original Message-----
From: teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com]
Sent: Friday, March 20, 2009 1:14 PM
To: Hemant Singh (shemant); v6ops@ops.ietf.org
Cc: Wes Beebee (wbeebee)
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.
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)