Subject: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 16 Apr 2010 13:10:31 +0200

Hi all,

Resulting from the discussion we are having on the nemo-pd draft, I'd
like to ask the WG if they consider OK to describe only the following
approach in the draft:

- "DHCPv6 Relay Agent for transmission of DHCPv6 messages" While not at
home, the MR uses a DHPCv6 relay agent function co-located in the MR
with the DHCPv6 client function is used to send the DHCPv6 signalling
through the MR-HA tunnel. This avoids us to make use of the exception
formulated in Section 10.4.4 of RFC3775 about the processing of DHCPv6
traffic (the tunnel is used instead of RH2 for that particular case).
The relay function would be deactivated when the MR is at home.

I'm fine with this change, but I'd like to know the opinion of the WG
before implementing it.

Thanks,

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 16 Apr 2010 15:43:30 +0200

Le 16/04/2010 13:10, Carlos Jesús Bernardos Cano a écrit :
> Hi all,
>
> Resulting from the discussion we are having on the nemo-pd draft,
> I'd like to ask the WG if they consider OK to describe only the
> following approach in the draft:
>
> - "DHCPv6 Relay Agent for transmission of DHCPv6 messages" While not
>  at home, the MR uses a DHPCv6 relay agent function co-located in the
>  MR with the DHCPv6 client function is used to send the DHCPv6
> signalling through the MR-HA tunnel.

The phrase is too long, better separate right before the last "is" to
make me understand what you mean.  Or similar.

> This avoids us to make use of the exception formulated in Section
> 10.4.4 of RFC3775 about the processing of DHCPv6 traffic (the tunnel
>  is used instead of RH2 for that particular case). The relay function
>  would be deactivated when the MR is at home.
>
> I'm fine with this change, but I'd like to know the opinion of the
> WG before implementing it.

Personally, I think I can sense what you mean: MR runs DHCPRelay and
DHCPClient (in addition to potentially being a DHCPServer too for LFNs,
which you don't say).

I personally do not agree with MR simultaneously running a Relay and a
Client. I will not go towards implementing it.  I prefer a solution
where MR is a DHCPClient and eventually a DHCPServer (no DHCPRelay in MR).

Yours,

Alex

>
> Thanks,
>
> Carlos
>
>
>
>
> _______________________________________________ MEXT mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mext

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 16 Apr 2010 09:42:27 -0700

Hello Carlos,

Thanks for following up on this. I'm commenting below on the alternative to the approach to makes sure we're all on the same page and can make an educated choice.

> I'm fine with this change, but I'd like to know the opinion of the WG

If we don't carry on with this change, we would have to do two things:

1. carry DHCP requests which are sourced from the MR link-local address and destined to a link-local multicast address inside the tunnel. 

2. carry DHCP replies destined to the MR link-local address inside the tunnel.

There are issues involved with both 1 and 2. It is not entirely clear how to afford IPsec protection to a multicast DHCP request involved in 1 when dynamic keying is used, and dynamic keying SHOULD be used as per BCP 107. It is also cumbersome to exempt the DHCP reply involved in 2 from RH2-tunneling -- although this issue might go away as we're currently discussing removing from 3775bis the RH2-tunneling for traffic locally generated at the HA .  

In light of the above I hope everybody is convinced that the alternative is not an option -- and as a result that we should go for the approach that Carlos proposes above (as originally proposed by Francis Dupont.) 

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 16 Apr 2010 19:27:12 +0200

Hi Alex,

> make me understand what you mean.  Or similar.

Sorry, I didn't pay the attention it deserve to write that sentence. The
idea is the MR uses a DHCPv6 relay agent and client entities co-located
(when the MR is not at home). This allows to use the MR-HA tunnel for
the DHCPv6 signalling. When the MR is at home the relay client
functionality is deactivated.

> DHCPClient (in addition to potentially being a DHCPServer too for LFNs,

Right.

> where MR is a DHCPClient and eventually a DHCPServer (no DHCPRelay in MR).

But then we have the issues derived of how to transport the link-local
signalling generated by the DHCPv6 signalling generated at the MR (it
seems to be possible to use the tunnel using the exception explained in
section 10.4.4 of RFC 3775, but this is not completely clear). I know
you prefer to use first DHCPv6 without any tunneling between the MR and
the HA, but I still think this is not that simple. Relying on relays at
the ARs of the visited networks is not a reasonable assumption, I guess.
On the other hand, running unicast DHCPv6 with global addresses has some
restrictions (or at least this is what I understand from RFC 3315) and
in this way -- as Julien pointed out -- we cannot reuse the IPsec
security mechanism used for the NEMO signalling.

Thanks,

Carlos

> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Apr 2010 22:49:49 +0200

Le 16/04/2010 18:42, Laganier, Julien a écrit :
> Hello Carlos,
>
> Thanks for following up on this. I'm commenting below on the
> alternative to the approach to makes sure we're all on the same page
> and can make an educated choice.
>
>> - "DHCPv6 Relay Agent for transmission of DHCPv6 messages" While
>> not at home, the MR uses a DHPCv6 relay agent function co-located
>> in the MR with the DHCPv6 client function is used to send the
>> DHCPv6 signalling through the MR-HA tunnel. This avoids us to make
>> use of the exception formulated in Section 10.4.4 of RFC3775 about
>> the processing of DHCPv6 traffic (the tunnel is used instead of RH2
>> for that particular case). The relay function would be deactivated
>> when the MR is at home.
>>
> 1. carry DHCP requests which are sourced from the MR link-local
> address and destined to a link-local multicast address inside the
> tunnel.

Not sure why should we encapsulate DHCP messages.

> 2. carry DHCP replies destined to the MR link-local address inside

ok... but if we wouldn't use a tunnel for encapsulate DHCP then have the 
DHCP replies unicast (non-encapsulated) would work too.

Alex

>
> There are issues involved with both 1 and 2. It is not entirely clear
> how to afford IPsec protection to a multicast DHCP request involved
> in 1 when dynamic keying is used, and dynamic keying SHOULD be used
> as per BCP 107. It is also cumbersome to exempt the DHCP reply
> involved in 2 from RH2-tunneling -- although this issue might go away
> as we're currently discussing removing from 3775bis the RH2-tunneling
> for traffic locally generated at the HA .
>
> In light of the above I hope everybody is convinced that the
> alternative is not an option -- and as a result that we should go for
> the approach that Carlos proposes above (as originally proposed by
> Francis Dupont.)
>
> --julien _______________________________________________ MEXT mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Apr 2010 22:53:39 +0200

Le 16/04/2010 19:27, Carlos Jesús Bernardos Cano a écrit :
>>> DHCPv6 signalling through the MR-HA tunnel.
>>
>> The phrase is too long, better separate right before the last "is"
>> to make me understand what you mean.  Or similar.
>>
>
> Sorry, I didn't pay the attention it deserve to write that sentence.
> The idea is the MR uses a DHCPv6 relay agent and client entities
> co-located (when the MR is not at home). This allows to use the
> MR-HA tunnel for the DHCPv6 signalling. When the MR is at home the
> relay client functionality is deactivated.
>
>>> 10.4.4 of RFC3775 about the processing of DHCPv6 traffic (the
>>> tunnel is used instead of RH2 for that particular case). The
>>> relay function would be deactivated when the MR is at home.
>>>
>>> I'm fine with this change, but I'd like to know the opinion of
>>> the WG before implementing it.
>>
>> Personally, I think I can sense what you mean: MR runs DHCPRelay
>> and DHCPClient (in addition to potentially being a DHCPServer too
>> for LFNs, which you don't say).
>
> Right.
>
>>
>> I personally do not agree with MR simultaneously running a Relay
>> and a Client. I will not go towards implementing it.  I prefer a
>> solution where MR is a DHCPClient and eventually a DHCPServer (no
>> DHCPRelay in MR).
>
> But then we have the issues derived of how to transport the
> link-local signalling generated by the DHCPv6 signalling generated
> at the MR

I see that link local signalling happening between the MR and the AR
exclusively, and AR use globaly addressed messages to talk to whomever
it wants to (be it the DHCP Server in the home domain, if needed).

I mean to suggest to make MR run DHCP naturally vanilla, clear interface
between MR and the AR (Access Router).

If there's a problem of AR not able to query the DHCP Server of _this_
MR then solve the problem at that place - between AR and DHCP Server:
(would the DHCP Relay in AR be able to recognize somehting in the DHCP
Solicit coming from MR and further contact the right DHCP Server?).

I mean if there's a problem between AR and DHCPServer then don't solve
it at MR, but at AR and DHCPServer.

> (it seems to be possible to use the tunnel using the exception
> explained in section 10.4.4 of RFC 3775, but this is not completely
> clear). I know you prefer to use first DHCPv6 without any tunneling
> between the MR and the HA, but I still think this is not that
> simple. Relying on relays at the ARs of the visited networks is not
> a reasonable assumption, I guess.

Why?

> On the other hand, running unicast DHCPv6 with global addresses has
> some restrictions (or at least this is what I understand from RFC
> 3315) and in this way -- as Julien pointed out --

Well... hm.  I must check the restrictions Julien talks about and you
refer to, so I am sure I understand.  Later.

> [doing DHCP non-encapsulated in MIP makes that] we cannot reuse the
> IPsec security mechanism used for the NEMO signalling.

Not sure... IPsec is IPsec, it's not like NEMO (or MIP6) had some
special IPsec.  That IPsec could be used to protect DHCP, if we
absolutely wanted to.

Alex

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 21 Apr 2010 16:36:46 -0700

Alexandru Petrescu wrote:
> Sent: Tuesday, April 20, 2010 1:50 PM
> To: [email-masked]
> Subject: Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at
> the MR for DHCPv6PD in NEMO
> 

Because when the MR is in a visited network, we need the DHCP messages to go to (a DHCP server in) the home network. 

Since there are situations (arguably the majority) where a visited network does not know where the MR's home network is, we cannot rely on a DHCP relay in the visited network to relay the MR's DHCP request to the home network.

In that situation, a practical and simple solution is to have the MR to tunnel its DHCP request up to the HA, that is, in the home network.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Apr 2010 19:32:26 +0200

Le 22/04/2010 01:36, Laganier, Julien a écrit :
>> Sent: Tuesday, April 20, 2010 1:50 PM To: [email-masked] Subject:
>> Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR
>> for DHCPv6PD in NEMO
>>
>>> alternative to the approach to makes sure we're all on the same
>>> page and can make an educated choice.
>>>
>>>> Resulting from the discussion we are having on the nemo-pd
>>>> draft, I'd like to ask the WG if they consider OK to describe
>>>> only the following approach in the draft:
>>>>
>>>> - "DHCPv6 Relay Agent for transmission of DHCPv6 messages"
>>>> While not at home, the MR uses a DHPCv6 relay agent function
>>>> co-located in the MR with the DHCPv6 client function is used to
>>>> send the DHCPv6 signalling through the MR-HA tunnel. This
>>>> avoids us to make use of the exception formulated in Section
>>> address and destined to a link-local multicast address inside
>>> the tunnel.
>>
> Because when the MR is in a visited network, we need the DHCP
> messages to go to (a DHCP server in) the home network.

Right.

> Since there are situations (arguably the majority)

Could we argue about that majority?

> where a visited network does not know where the MR's home network
> is,

Could the DHCP Relay (within the AR) have a means to inspect the DHCP
Solicit and to forward it to a particular DHCP Server based on a value
found on that Solicit?

(I am asking because there exist already means in the DHCP Request to
specify a form of identity of the Client such that the Server allocates
a specific address to it.)

> we cannot rely on a DHCP relay in the visited network to relay the
> MR's DHCP request to the home network.
>
> In that situation, a practical and simple solution is to have the MR
>  to tunnel its DHCP request up to the HA, that is, in the home
> network.

TO me it looks strange to encapsulate DHCP within IP-in-IP messages (be
them those of MIP).  I have never seen DHCP encapsulated so.

Alex

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 22 Apr 2010 10:55:27 -0700

Alex - 

Alexandru Petrescu wrote:
> [...]

If you find that something is broken in the proposed approach, please feel free to explain why and suggests solutions.

So far I've only seen your opinions and preferences, and I do not understand how they relate to the discussion we're having when they are not substantiated by technical facts.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 22 Apr 2010 10:59:34 -0700

> Could we argue about that majority?

I don't see the point in arguing about majorities. These situations exist (e.g. any residential LAN behind a home CPE) and that is sufficient for the sake of this discussion.

> Solicit and to forward it to a particular DHCP Server based on a value

A DHCPv6 relay does not inspect the DHCPv6 messages it relays from client.
 
> them those of MIP).  I have never seen DHCP encapsulated so.

It is not surprising that you have never seen DHCP PD encapsulated in a Mobile IP tunnel because so far DHCP PD was not used to configure a Mobile Router, which is the reason we are working on this specification.

That being said, we are trying to resolve an issue as part of the WGLC in this document. If you find that something is broken in the proposed approach, please feel free to explain why and suggests solutions.

Absent that, I'm afraid that this discussion does not have much value in helping the WG move forward.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Apr 2010 20:04:11 +0200

Le 22/04/2010 19:55, Laganier, Julien a écrit :
> If you find that something is broken in the proposed approach,
> please feel free to explain why and suggests solutions.

Broken - encapsulate link-local packets to send across the Internet.

Broken - run DHCP after having run BU-BAck.

Broken - absence of knowledge of the assigned MNP at HA - security
checks can't be ensured.

Solution suggested - do not encapsulate DHCP.

Relay co-located with Client, in the MR, is a tweak found in practice,
which doesn't address any problem we have, and that one would like to
standardize.

> So far I've only seen your opinions and preferences, and I do not
> understand how they relate to the discussion we're having when they
> are not substantiated by technical facts.

I will listen to other opinions.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Apr 2010 20:13:51 +0200

Le 22/04/2010 19:59, Laganier, Julien a écrit :
>>>> Sent: Tuesday, April 20, 2010 1:50 PM To: [email-masked]
>>>> Subject: Re: [MEXT] DHCPv6 relay co-located with the DHCPv6
>>>> client at the MR for DHCPv6PD in NEMO
>>>>
>>>>>  alternative to the approach to makes sure we're all on the
>>>>> same page and can make an educated choice.
>>>>>
>>>>>>  draft, I'd like to ask the WG if they consider OK to
>>>>>> describe only the following approach in the draft:
>>>>>>
>>>>>>  While not at home, the MR uses a DHPCv6 relay agent
>>>>>> function co-located in the MR with the DHCPv6 client
>>>>>> function is used to send the DHCPv6 signalling through the
>>>>>> MR-HA tunnel. This avoids us to make use of the exception
>>>>>> formulated in Section 10.4.4 of RFC3775 about the
>>>>>> processing of DHCPv6 traffic (the tunnel is used instead
>>>>>> of RH2 for that particular case). The relay function would
>>>>>> be deactivated when the MR is at home.
>>>>>>
>>>>>> I'm fine with this change, but I'd like to know the
>>>>>> opinion of the WG before implementing it.
>>>>>
>>>>> 1. carry DHCP requests which are sourced from the MR
>>>>> link-local address and destined to a link-local multicast
>>>>> address inside the tunnel.
>>>>
> I don't see the point in arguing about majorities. These situations
> exist (e.g. any residential LAN behind a home CPE) and that is
> sufficient for the sake of this discussion.

That is one perspective.  I think like you want to explain that we
couldn't touch the home CPE (AR), right?  Well if we couldn't then
that's a requirement and should be stated.

I disagree with it.  I can explain why, if you're interested.

It seems to me very strange to assume we can't touch AR yet we need
dynamic allocation of MNP, as if we could control some large farm of HAs
and MNPs (is that an operator? - if yes, then operator operates  ARs too).

>> Could the DHCP Relay (within the AR) have a means to inspect the
>> DHCP Solicit and to forward it to a particular DHCP Server based
>> on a value found on that Solicit?
>

NEver ever?  COuld we suggest some modifications so it does so?

>> (I am asking because there exist already means in the DHCP Request
>> to specify a form of identity of the Client such that the Server
>> allocates a specific address to it.)
>>
>>> we cannot rely on a DHCP relay in the visited network to relay
>>> the MR's DHCP request to the home network.
>>>
>>> In that situation, a practical and simple solution is to have
>>> the MR to tunnel its DHCP request up to the HA, that is, in the
>>> home network.
>>
>> TO me it looks strange to encapsulate DHCP within IP-in-IP
>> messages (be them those of MIP).  I have never seen DHCP
>> encapsulated so.
>
> It is not surprising that you have never seen DHCP PD encapsulated
> in a Mobile IP tunnel because so far DHCP PD was not used to
> configure a Mobile Router, which is the reason we are working on
> this specification.

WEll yes, I agree, but I could have seen DHCP encapsulated in other
tunnels than MIP, because, for example, one may need DHCPv6-PD through
some IPv4 tunnel as part of some transition method - yet I don't see it.

I could have seen DHCP encapsulated in other things... like multicast or
http, or something else... yet never seen it.

> That being said, we are trying to resolve an issue as part of the
> WGLC in this document. If you find that something is broken in the
> proposed approach, please feel free to explain why and suggests
> solutions.
>

Well good luck, I will listen.

Alex

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 22 Apr 2010 11:27:18 -0700

> Broken - encapsulate link-local packets to send across the Internet.

No link-local packet is encapsulated. The packet that the DHCP client on the MR generates is relayed by a DHCP relay in the MR. This packet can be sent using global unicast addresses.

> Broken - run DHCP after having run BU-BAck.

I don't see what's broken per se in this.

> Broken - absence of knowledge of the assigned MNP at HA - security

Nothing is broken when the MR operates in implicit mode since the relevant provision of RFC 3963 is satisfied:

   If the Mobile Router sends a Binding Update with a one or more Mobile
   Network Prefix options, the Home Agent MUST be able to verify that
   the Mobile Router is authorized for the prefixes before setting up
   forwarding for the prefixes.
 
No prefixes are being sent in implicit mode. Setting up the forwarding happens as a result of the DHCP PD signaling inside the tunnel, authenticated by an IPsec SA.

> which doesn't address any problem we have, and that one would like to

Nothing is broken with the remedies we're proposing -- see above.

On the other hand, the "solution" (I use brackets because in my view a solution solves a problem and in this case I do not know what the problem is) you are suggesting is at best, to put it mildly, unspecified.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Apr 2010 20:49:45 +0200

Le 22/04/2010 20:27, Laganier, Julien a écrit :
>>>> I personally do not agree with MR simultaneously running a
>>>> Relay and a Client. I will not go towards implementing it.  I
>>>> prefer a solution where MR is a DHCPClient and eventually a
>>>> DHCPServer (no DHCPRelay in MR).
>>>
> No link-local packet is encapsulated. The packet that the DHCP
> client on the MR generates is relayed by a DHCP relay in the MR.

So it's a link-local packet which doesn't leave the computer, it doesn't
go on any link.  This is strange.

> This packet can be sent using global unicast addresses.

How does the Relay on MR know the address of its DHCP Server?  If MR 
could, why AR couldn't?

What does the MR DHCP Relay put in its source address - its CoA?  Will 
the DHCP Server in the Home Domain accept any such packets sourced from 
arbitrary addresses claiming to be Relays?  I doubt so.

> I don't see what's broken per se in this.

It's broken because too complex and unnatural.

> Nothing is broken when the MR operates in implicit mode since the
> relevant provision of RFC 3963 is satisfied:

Ok but then don't come back saying you need to modify NEMOv6 spec such 
that it can dynamically switch between implicit and explicit modes. 
BEtter modify DHCP to satisfy the requirements.

> No prefixes are being sent in implicit mode. Setting up the
> forwarding happens as a result of the DHCP PD signaling inside the
> tunnel, authenticated by an IPsec SA.
>
>> Relay co-located with Client, in the MR, is a tweak found in
>> practice, which doesn't address any problem we have, and that one
>> would like to standardize.
>
> On the other hand, the "solution" (I use brackets because in my view
> a solution solves a problem and in this case I do not know what the
> problem is) you are suggesting is at best, to put it mildly,
> unspecified.

Right, we don't have a clear idea about what the problem is - I agree in 
this sense.

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 24 Apr 2010 07:46:23 -0700 (PDT)

Hi Alex,
  The problems you listed below had long been identified and an alternative solution based on BU/BA was proposed by Pascal and TJ, this draft which was a WG draft can be found at:
http://tools.ietf.org/html/draft-ietf-nemo-prefix-delegation-02
Correct me if I am wrong.

Since this draft was not followed up, we had come up with a similar solution, it could be found in the I-D archive.

Regards,

Behcet

----- Original Message ----
> From: Alexandru Petrescu <[email-masked]>
> To: "Laganier, Julien" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Thu, April 22, 2010 1:04:11 PM
> Subject: Re: [MEXT] DHCPv6 relay co-located with the DHCPv6 client at the MR for DHCPv6PD in NEMO
> 
>> and 
> a Client. I will not go towards implementing it.  I prefer a
>> 

Broken - encapsulate link-local packets to send across the 
> Internet.

Broken - 
> absence of knowledge of the assigned MNP at HA - security
checks can't be 
> ensured.

Relay 
> co-located with Client, in the MR, is a tweak found in practice,
which 
> doesn't address any problem we have, and that one would like 
> to
standardize.

Alex

> --julien

_______________________________________________
MEXT 
> mailing list

> href="mailto:[email-masked]">[email-masked]

> href="https://www.ietf.org/mailman/listinfo/mext" target=_blank

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Apr 2010 20:16:04 +0200

Hi Behcet and thanks for the pointer.

IMHO.

It is not clear to me whether the 2007 draft you cited
(draft-ietf-nemo-prefix-delegation-02) addresses the problems listed in
the recent discussion.

That draft uses BU extensions (new BU bit) as part of the MIPv6
protocol.  I disagree with it, because DHCPv6-PD is better than DHCPv6
at allocating prefixes, and already implemented, and already used.  I do
not see why extending MIPv6 to allocate prefixes.

To me (IMHO) a good solution would use DHCPv6-PD non-encapsulated,
between MR and AR-Relay.

Generally speaking, if I had to describe the need:

-need to allocate dynamically an MNP to the MR.
-need to perform it securely: some of the risks are: (1) an MR could
  falsely request a prefix prior to having identified itself to HA using
  its MIP6 keys, (2) the HA may miss the allocated MNP from its Prefix
  Table and thus couldn't ensure the MNP in the explicit mode BU is
  legitimate.
-need to reuse the NEMOv6 MIP6 protocol unmodified.
-need to reuse existing protocols naturally fit for prefix allocation.
-reliability: need to allocate a prefix to MR even when the MIPv6
  implementation fails; this is good in order to allow in-mobile network
  communication between LFNs; MIP6 may fail when the MR is disconnected,
  and when MIP traffic blocked by firewalls in the access networks.
-need to inform the HA about the MNP allocated to the mobile network,
  such that NEMOv6 MIP6 implementation works unmodified, and is able to
  check the presence of the prefix in the NEMOv6 Prefix Table.

This is of course IMHO.

If the WG believes otherwise about these needs, I am listening.

Alex

Le 24/04/2010 16:46, Behcet Sarikaya a écrit :
> Hi Alex, The problems you listed below had long been identified and
> an alternative solution based on BU/BA was proposed by Pascal and TJ,
> this draft which was a WG draft can be found at:
> Since this draft was not followed up, we had come up with a similar
> solution, it could be found in the I-D archive.
>
> Regards,
>
> Behcet
>
>
>
>> From: Alexandru Petrescu<[email-masked]> To:
>> "Laganier, Julien"<[email-masked]> Cc:
>> "[email-masked]"<[email-masked]> Sent: Thu, April 22, 2010 1:04:11
>> PM Subject: Re: [MEXT] DHCPv6 relay co-located with the DHCPv6
>> Le 22/04/2010 19:55, Laganier, Julien a écrit : Alex -
>>
>>
>> doesn't address any problem we have, and that one would like to
> standardize.
>
>> understand how they relate to the discussion we're having when
>> they are not substantiated by technical facts.
>