the Terpedo after isp ipv6 offering later, function, quandary, and set at sg3xx routes remaining:
- os such vista 2002:...via it got ipv6 first,
- found 2001:… prefix , added after, resulting no.e nothing ipv6 showing?
- isp claiming not their scope managing Teredo , who set ipv4 1800 time on, to dhcpv4 server isp, as well Terredo servers to care off these, when IPv6 Only is a dreaming yet reality completely ?
Sincerely
Li H
On Mon, Jun 8, 2020, 19:14 Jaime Jiménez <jaime@xxxxxx> wrote:
Hi Carlos,
I believe this solves all of the issues I raised on my review. Thanks
for the prompt response, I wrote some comments below.
Ciao,
-- Jaime Jiménez
On Sun, Jun 07, 2020 at 11:45:07AM +0200, CARLOS JESUS BERNARDOS CANO wrote:
> Hi Jaime,
>
> Thanks a lot for your review. Please see my comments and responses inline
> below.
>
> On Thu, Jun 4, 2020 at 9:58 AM Jaime Jimenez via Datatracker <
> noreply@xxxxxxxx> wrote:
>
> > Reviewer: Jaime Jimenez
> > Review result: Ready with Nits
> >
> > draft-ietf-dhc-slap-quadrant-07 iodir review
> > ============================================
> >
> > This draft is complementary to draft-ietf-dhc-mac-assign. It defines
> > mechanisms
> > to allow for the use of IEEE's SLAP quadrant when using DHCP for MAC
> > allocation. It also defines a new DHCPv6 Option (QUAD) for that purpose.
> >
> > Both drafts verse on the use of DHCP to assign MAC addresses to hosts,
> > which as
> > a concept was strange to me to begin with. However I am not up-to-date in
> > the
> > latest developments on host configuration so I am likely to be missing a
> > big
> > part of the picture.
> >
> > I find this draft quite useful to understand the rationale behind
> > draft-ietf-dhc-mac-assign, and I regret not having paid more attention to
> > it
> > before I did the draft-ietf-dhc-mac-assign review. At the time I
> > understood the
> > rationale to be the use of MAC address as a deployment mechanisms while in
> > reality, it is a privacy mechanism. I think the security scenario makes
> > more
> > sense as IoT devices normally are deployed with MAC information from the
> > factory. I believe that is the primary purpose of both dhc-slap-quadrant
> > and
> > draft-ietf-dhc-mac-assign when it comes to IoT, perhaps that information
> > should
> > be emphasized on draft-ietf-dhc-mac-assign.
> >
> > This draft is clearly written and seems ready, below are few concrete
> > comments:
> >
> > Abstract:
> >
> > Consider splitting in two shorter sentences the paragraph below.
> >
> > " [...] Recently, the IEEE
> > has been working on a new specification (IEEE 802c) which defines a
> > new "optional Structured Local Address Plan" (SLAP) that specifies
> > different assignment approaches in four specified regions of the
> > local MAC address space."
> >
>
> [Carlos] Done. Changes applied in -10 version (to be released after
> collecting all comments from IESG review).
>
[Jaime] OK
>
> > Section 1:
> >
> > s/specified regions/regions/ ?
> > "different assignment approaches in four specified regions of the"
> >
>
> [Carlos] Since IEEE 802c also defines the regions, we believe it's better
> to keep the original wording to make this more explicit.
>
>
[Jaime] OK
> >
> > Section 3:
> >
> > "[...] if the IoT device can move, then it might prefer to
> > select the SAI or AAI quadrants to minimize address collisions
> > when moving to another network."
> >
> > I wonder if collisions are likely to occur in practice.
> >
>
> [Carlos] Collisions are always possible, since devices can always select
> their own address without using a delegation mechanism, but not very
> likely. draft-ietf-dhc-mac-assign has some security considerations about
> address collisions.
>
[Jaime] Thanks, if you have some literature on the topic, I'd be happy to read
it off-list.
>
> >
> > Section 4.1:
> >
> > Naive questions on MAC usage. Could an IoT device self-assign a MAC
> > with a
> > specific SLAP quadrant information? Would the DHCP Server accept it
> > without
> > the negotiation mechanisms described here (providing it is not in the
> > MAC
> > address pool)? Could an endpoint use an OUI from a different vendor?
> > If so,
> > how are potential collisions or attacks preventable?
> >
>
> [Carlos] It is always possible that a device self-assigns a MAC address
> from any quadrant, though for some quadrants it is not the expected use
> (therefore, if a device does it, it would not be behaving as
> specified). draft-ietf-dhc-mac-assign has some security considerations
> about address collisions that would apply here as well.
>
>
[Jaime] draft-ietf-dhc-mac-assign Security considerations where rather thin too,
mostly the references to RFC8415 and RFC8200 and the mention of link-layer
address collision. If that is the only new issue then that's OK, I
assume the SECDIR had a look on it.
> > "[...] The server MAY alter the
> > allocation at this time."
> >
> > It would be helpful to explain in which way allocation might be altered
> > (i.e., by reducing the address block)
> >
>
> [Carlos] OK, we have added some examples in -10.
>
>
[Jaime] I am unable to find -10 but I trust the changes are addressed.
> >
> > "5. When the assigned addresses are about to expire, the client sends
> > a Renew message. It includes the preferred SLAP quadrant(s) in
> > the new QUAD IA_LL-option, so in case the server is unable to
> > extend the lifetime on the existing address(es), the preferred
> > quadrants are known for the allocation of any "new" addresses."
> >
> > Is it correct to assume that step 5 causes either:
> > - to assign the existing block
> > - to start on step 1 with the new QUAD if the block is no longer
> > available.
> >
>
> [Carlos] Not sure I got it right, but Step 5 does not cause going back to
> step 1. It basically includes the preferred SLAP quadrants again to
> facilitate the server allocating _different_ addresses to the ones the
> client got assigned, in case the server cannot extend the lifetime of these
> ones (e.g., because of a renumbering policy).
>
>
[Jaime] When we say "preferred SLAP quadrants" are we to assume that they are
the same the client has already been using or is that an uncommon case?
I would maybe write a sentence or two including your explanation and
some normative text (e.g., that the client MAY try with the existing ones and
that the server MAY assign different ones due to renumbering or other factors).
> > So, is it then the case that the client sends a Renew message -for the
> > existing block- with _alternative_ SLAP quadrants different than the
> > ones
> > in use in case the block is no longer available?
> >
>
> [Carlos] Please check if my response beforer clarifies this.
>
>
[Jaime] From the previous response I understand that the client can choose to
request the same SLAP quadrant or another different one.
> >
> > "6. The server responds with a Reply message, including an LLADDR
> > option with extended lifetime."
> >
> > What happens with the _fail_ case, in which the block is no longer
> > available? How is the REPLY format denying the addresses?
> >
>
> [Carlos] In this case the client would know by checking the allocated
> address(es) (if they are different, that means that the addresses are no
> longer available, and the client would know from which quadrant they belong
> to, as this is implicit from the address itself).
>
>
[Jaime] OK so the server will _always_ reply with some address
allocation. Could this mechanism not be abused by clients requesting
new blocks too frequently?
> > A style suggestion, as "Advertise", "Renew", "Reply", etc are specific
> > DHCP
> > message types, you might want to write them capitalized "ADVERTISE",
> > "RENEW", "REPLY", etc to avoid potential confusion.
> >
>
> [Carlos] Here we've followed the same approach as
> in draft-ietf-dhc-mac-assign. If we change it, we should do it in both..
>
>
[Jaime] It was just a style suggestion, someone versed in the field will
probably know it right away. So, it's up to the authors.
> > Section 4.2:
> >
> > "9. When the assigned addresses are about to expire, the client
> > sends a Renew message.
> > [...]
> > 12. The relay sends the Reply message back to the client."
> >
> > Same as in section 4.1, steps 9 to 12 might need to be revised.
> >
>
> [Carlos] Please see if my responses to 4.1 are satisfactory.
>
[Jaime] I think the Relay behaviour is OK as described.
>
> >
> > Section 7:
> >
> > The Security section looks a bit thin but I have no good suggestions to
> > improve. Is it even possible for a bad actor to spoof a RENEW lease on
> > behalf of another node? Perhaps some information on authentication
> > mechanisms for DHCP would be handy.
> >
>
> [Carlos] We mainly refer to RFC 8415 and RFC 7227 for all the security
> mechanisms of DHCP, and also to draft-ietf-dhc-mac-assign for some
> additional considerations regarding link-layer address assignments using
> DHCP.
>
>
[Jaime] As I mentioned above, if the authors consider that new potential
threats are covered and SECDIR is fine then it should be OK.
> > References:
> >
> > [IEEEStd802c-2017] does not provide a link to the document. It would be
> > useful to include that when available.
> >
>
> [Carlos] OK, noted. Thanks.
>
[Jaime] Thanks!
> Thanks a lot.
>
> Carlos
_______________________________________________
dhcwg mailing list
dhcwg@xxxxxxxx
https://www.ietf.org/mailman/listinfo/dhcwg
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
