Daniel,
We have talked in the past within the working group about how should a CPE
decide in which mode to boot:
IPv4-only, IPv6-only, full dual-stack, DS-Lite or 6rd...
We agreed to punt this until the specs were completed, so now would be the time
to restart this effort.
The technique that was proposed a few years back is for the CPE to start both
DHCPv4 and DHCPv6
at the same time and see if a 6rd option or DS-Lite option comes, and if it
does, about the other one.
As chair of the wg, I would welcome a document explaining this in more
details....
- Alain.
On Mar 1, 2011, at 3:49 PM, Daniel Roesen wrote:
> Hi Yiu,
>
> On Tue, Mar 01, 2011 at 08:07:48PM +0000, Lee, Yiu wrote:
>> draft-ietf-softwire-ds-lite-tunnel-option defines the behavior how the B4
>> obtains the AFTR information. It is not to define to use dhcp to signal
>> the B4 to use dual-stack mode or ds-lite mode.
>
> What would be the more appropriate place if not there?
>
> Even if deemed out of scope, wouldn't a correction to the RFC3315 reference
> ("will not reply") be imperative? Or do I misread something?
>
>> For your question, if the ISP provisions the dhcp server not to respond
>> dhcpv4 request from the B4, the B4 would use dhcpv6 to obtain the AFTR
>> information. This should be sufficient.
>
> So your suggestion would be to have the CPE implementing DS-Lite to
> always ask for the AFTR address, but enable DS-Lite mode automatically
> only and exactly if the DHCPv4 request fails?
>
> I think there should be some guidance on recommended CPE router
> behaviour in either the ds-lite spec or the ds-lite DHCP option spec.
> Otherwise, I see DS-Lite coming in CPE routers as just an option which
> needs to be manually turned on by the customer - or every CPE router
> vendor developing their own heuristics. We'd like to avoid that.
> How to enforce DS-Lite operations is something that should be
> standardised so we can point vendors on the specification how to behave.
>
> We could probably stick it into the v6ops cpe-router-bis draft, but that
> would mean that this document needs guidance for every transition
> mechanism with similar scenarios - wouldn't it be better to describe
> desired CPE behaviour for a specific transition technologie in the spec
> of that?
>
> Best regards,
> Daniel
>
> --
> CLUE-RIPE -- Jabber: [email protected] -- dr@IRCnet -- PGP: 0xA85C8AA0
> _______________________________________________
> Softwires mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
