> Given the following network:
>
>
> ISP (Location of DHCPv6 server)
> |
> |
> CPE /48
> / \
> / \
> ---BA---
>||
>
>
> Is it possible to configure the DHCP server to allocate
> Thanks for the suggestion, but I'm afraid the text you proposed will
> simply make the specification unnecessarily ambiguous.
Yes, you're probably right, it should be a little less ambiguous.
> I'd like to repeat my points, which are:
>
> 1. I personally do not think it makes sense to update th
> I find the language somewhat confusing. This is what I undestand the paragraph
> to say:
[...]
Yes, this is what the paragraph means and I agree with Jinmei that we
should include this short note in rfc2462bis.
Jinmei: I think that Gerrit's rewording is a little clearer. If you
don't mind I wo
Jinmei,
> That is, the valid and preferred lifetimes of an address configured by
> DHCPv6 (the "stateful" protocol) can be updated by succeeding RAs.
> Does this really make sense? For example, consider the following
> scenario:
I personally think that it makes sense to keep this specification. T
> I'm not sure if we need to take a particular action for this in
> rfc2462bis, but you may want to add a note like this in Section 5.5.2:
>
> Note that it is possible that there is no router on the link in this
> sense but is a node that has the ability to forward packets. In
> this case,
Jinmei,
> Thanks for the feedback on this subject so far.
thank you for the comprehensive summary, it looks very good!
> 11. revise Section 5.5.2 as follows:
>
>Even if a link has no routers, stateful autoconfiguration to obtain
>addresses and other configuration information may still b
Christian,
> When writing standards, less is more. If we are not sure about
> something, it is probably better to just leave it out.
yes, I agree with you. That's why I suggested to use the text only if
the "may"s as Tim suggested seem to be an appropriate choice. But I see
your point in leaving t
> Let me check...this should apply to the current RFC2462, shouldn't it?
> I'm not sure why you are making this point in this context...
No, I was referring to your suggestion of writing a document (standard
or BCP) about the details of the protocol interaction which I believe is
a good idea becaus
> - how a host that implements DHCPv6 should behave. The host would
> have an internal (conceptual) variable, controlling the policy about
> autoconfiguration, which should have at least three values:
> 1: it should invoke DHCPv6 for address autoconfiguration regardless
> of the content
Ralph,
> The host behavior when the M/O flags transition from set to unset is a
> little less clear. In the case of the O flag, the host will stop using
> DHCPv6 for other configuration information. Should it also stop using the
> configuration information it received through DHCPv6?
>
> Simila
Jinmei,
> Explicit support or objections are highly appreciated. If the list is
> still silent, I'll start revising the document anyway.
I support all of your proposed changes.
Christian
IETF IPv6 working group mailing list
Arun,
before I write up a few comments I'd like to remark that I don't like
the idea of delegating prefixes using ICMPv6 because I don't see how
this offers different/better/more versatile features compared to
DHCPv6-PD. Especially since you need a state machinery or cache for this
mechanism to ma
> and so the exchange should fail at this stage.
I just realised some implications of your post. As I wrote in my other
mail, the client indeed does not need to send IA options and hence the
NoAddrsAvail will not be sent to the client in an Advertise message, if
no IA options are used in the first
> I support Christian's suggestion; they should be just hints.
I also support this suggestion.
> No flag is going to force the node to run a protocol. More often than
> not, for implementation simplicity, I'd guess most nodes (especially
> where DHCPv6 is available), the nodes are going to run
> If the client does not want address assignment, is it okay for the
> client to send a Solicit without including an IA option? It's not
That should be possible, yes. The purpose of a solicit message is to
find a DHCPv6 server or a relay agent, there's no implication that it
has some immediate co
I fully agree with the chair's decision to leave the M/O bits unchanged
for now.
I would like to quickly address (comments inline) the security argument
that was raised by Alain.
Alain,
> It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
> an automatic and insecure way to
> (Note: In this message, I'm basically speaking just as an individual
> in this list. I'll propose an action as a 2462bis editor after the
> entire discussion; it may or may not be same as what I'm going to say
> below)
I think your approach to look at the two sides of the medal is very
useful, b
Hi Tim, hi Ralph,
I also completely agree with Ralphs wording. Tim: regarding the issue
you address:
> So the question is should the wording of (a) and (b) be changed to reflect
> the processing text of (c)? On their own, (a) and (b) suggest that to get
> the behaviour of (c) *both* the M and O
Sorry for posting this comment, I saw the IPv6 Chairs' mail too late.
Christian
--
JOIN - IP Version 6 in the WiN Christian Strauf
A DFN project Westfälische Wilhelms-Universität Münster
http://www.join.uni-muenster.de Zentrum für Informationsverarbeitung
Team: [EMAIL PROTECTED
> But if I want a VoIP communication from me (behind a NAT) to some user
> behind a NAT, not using a 3rd party "location" server, how does v4 deliver,
> without the receiving user having the pain of port forwarding configuration
> on their NAT?
Good point. I experienced that end-users in the Gn
> Clearly many users care a lot about the isolation and little about the
> functionality that you believe is being limited. Rather than trying to
> convince them that they are wrong for wanting to keep their networks
> running, how about proposing a way to achieve that isolation without
> limiting
> My crystal ball is as cloudy as anyone's. But I would expect that it is all
> a matter of economics.
I very much agree with you on this point. The problem is that right now
it's too hard to sell IPv6 (in the literal sense of the word). I believe
that one of the reasons for this is that some fea
22 matches
Mail list logo
