Subject: [Mip6] Comments while reading draft-ietf-mip6-bootstrapping-split-02.txt

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 15:22:36 +0200

Dear authors of draft-ietf-mip6-bootstrapping-split-02.txt,  I have read
the draft and I have several comments.

> Mobile IPv6 [2] requires the Mobile Node to know its Home Agent 
> Address, its own Home Address and the cryptographic materials (e.g. 
> shared keys or certificates) needed to set up IPsec security 
> associations with the Home Agent in order to protect Mobile IPv6 
> signaling. This is generally referred to as the Mobile IPv6 
> bootstrapping problem [4]. [...] Mobile IPv6 base protocol does not
> specify any method to automatically acquire this information,

That is wrong from many respects. The first and foremost is with respect 
to the HA address.  rfc3775 does specify how to automatically acquire 
the HA address - DHAAD.

With respect to the Home Address, although rfc3775 does not
specify how MN could derive its Home Address, it still describes MPD
(Mobile Prefix Discovery) and the MPA (Advertisement) could be used by
MN to derive its Home Address by simple stateless auto-configuration.

With respect to the crypto material, the certificates more specifically.
  Neither Mobile IPv6 nor any other method I'm aware off will allow MN to
"automatically" acquire a cert.  To acquire a cert one must prove
its/his/her identity with an out-of-band method, non-automatisable.

So stating that the bootstrapping problem lies in the fact that Mobile 
IPv6 can't distribute certs makes one think that a solution to that 
problem may be this draft which will help to distribute certs.  It doesn't.

> which means that network administrators are normally required to 
> manually set configuration data on Mobile Nodes and HAs. However, in
>  real deployments, manual configuration does not scale as the Mobile
>  Nodes increase in number.

This leaves the reader the impression that while by RFC3775 the admins
will need to manually configure data on MN, this spec would require no
such pre-configuration, thus apparently more scalable.  The first part
is plain wrong.  This spec does require the pre-configuration of
something: the HA FQDN.  Should be acknowledged here, not deep in the
document.

The second part (the one that gives the impression that pre-configuring
data on MN is not scaling with the number of MNs) suddenly becomes a
non-supportive argument for this draft.  Because if pre-configuring data
on MN is not scalable then pre-configuring the FQDN is not scalable either.

Moreover, this spec requires additional data to be pre-configured on the
MN, not just the domain name.  It's the certificates.  They must be
pre-configured on MN in order to somehow avoid the fallacies of the
still insecure HA Discovery phase (as opposed to the insecure DHAAD).

(There is no automatic way to securely distribute certificates to MNs,
  so this must be a pre-configuration too.)

> o  HA address discovery. The Mobile Node needs to discover the 
> address of its Home Agent. The main objective of a bootstrapping 
> solution is to minimize the data pre-configured on the Mobile Node.

Ok, so the objective is to minimize the data pre-configured on the MN.

> For this reason, the DHAAD defined in [2] may not be applicable in 
> real deployments since it is required that the Mobile Node is 
> pre-configured with the home network prefix

Ok, so pre-configuring the home network prefix on the MN is not minimal.

> and it does not allow an operator to load balance by having Mobile 
> Nodes dynamically assigned to Home Agents located in different 
> subnets.

But was load balancing an objective?  The objective was to minimize
pre-configured data, not to offer load balancing capability.

> This document defines a solution for Home Agent address discovery 
> that is based on Domain Name Service (DNS), introducing a new DNS SRV
>  record [5]. The unique information that needs to be pre-configured 
> on the Mobile Node is the domain name of the MSP.

So there is a need to pre-configure data on the MN, except that this
time we pre-configure the domain name instead of the home prefix.

Is pre-configuring the domain name more minimal than pre-configuring the
home prefix?  I don't think we can talk in absolute terms here.  In
terms of memory required, a prefix can take maximum 39 ASCII characters
while a domain name may take any length ("domain" in domain.com can have
up to 255 characters).  So apparently pre-configuring a prefix could be
shorter than pre-configuring a domain name.

> An optional part of bootstrapping involves providing a way for the 
> Mobile Node to have its FQDN updated in the DNS with a dynamically 
> assigned home address.

More correct language would be to update the IN Resource Record
corresponding to its permanent FQDN.  Because "updating the FQDN with
something" may be read as changing the FQDN.  It doesn't change normally.

> The Mobile Node needs to obtain the IP address of the DNS server 
> before it can send a DNS request. This can be pre-configured on the 
> Mobile Node or obtained through DHCPv6 from the visited link [11].

"DNS server pre-configured on the MN"?  More data pre-configured?
Remark this would come in addition to the domain name pre-configured on
the MN.

But I do agree the DNS server address could come from the local DHCP server.

> In this case, the Mobile Node is configured with the Fully Qualified 
> Domain Name of the Home Agent. As an example, the Mobile Node could 
> be configured with the name "ha1.example.com", where "example.com" is
> the domain name of the MSP granting the mobility service.

I find this method relatively more flexible than the method SRV RR,
because it allows a specific HA to be associated to a specific subnet in
example.com (the SRV method doesn't).  However, it's still data to be
pre-configured on the MN, just like the home prefix.

> The service name for Mobile IPv6 Home Agent service as required by 
> RFC 2782 is "mip6" and the protocol name is "ipv6". Note that a 
> transport name cannot be used here because Mobile IPv6 does not run 
> over a transport protocol.

Would this require modifications to rfc2782 to explain that the Port
number in a SRV RR be optional?

The second question is: do we need IANA action for being able to use the
service name in SRV "mip6" ?  Because the IANA Considerations section
doesn't seem to mention it.

> The SRV RR has a DNS type code of 33. As an example, the Mobile 
> constructs a request with QNAME set to "_mip6._ipv6.example.com" and
>  QTYPE to SRV.

Thus, for a given domain example.com only one HA will be sent back by
DNS to MN.  Presumably, in a domain there are several subnets, and
various MNs have various subnets as their homes, all in the same domain.
  How would DNS resolve the right HA for the right MN when the only key
used is "_mip6._ipv6"?

Alex

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Apr 2006 11:19:30 -0700

hi Alex,

I will try to answer a couple of questions and
leave the rest to Gerardo. :)

Alexandru Petrescu wrote:
>> The service name for Mobile IPv6 Home Agent service as required by RFC 
>> 2782 is "mip6" and the protocol name is "ipv6". Note that a transport 
>> name cannot be used here because Mobile IPv6 does not run over a 
>> transport protocol.
> 

no need for modifications. it is just a string.
RFC 2782 says

    Proto
         The symbolic name of the desired protocol, with an underscore
         (_) prepended to prevent collisions with DNS labels that occur
         in nature.  _TCP and _UDP are at present the most useful values
         for this field, though any name defined by Assigned Numbers or
         locally may be used (as for Service).  The Proto is case
         insensitive.

> doesn't seem to mention it.

nope. IANA does not maintain this. for some
reason they are maintained at
http://www.dns-sd.org/ServiceTypes.html. I would
also like IANA to maintain the service types.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 24 Apr 2006 21:05:09 +0200

>         locally may be used (as for Service).  The Proto is case

Ok, got it.  The doubt was in that mentioning of "Assigned Numbers" and 
"local", because I was afraid that foreign domain may define "ipv6" as 
local while home domain might use "mip6" as local.  But the record is 
normally defined in only one place (presumably the home) and the foreign 
domains will just carry it.

> also like IANA to maintain the service types.

Maybe someone should write to srvtypes at that address, mixing in the 
IESG phase, inform the Name mip6 and Service ipv6 are used (?).  At 
least the ipv6 keyword has a large potential that people may be 
interested in.

Not to forget it, this SRV method lacks the capability to deliver to MN 
the home prefix the MN has seen previously (either because it was at 
home, or because this is a 2nd bootstrap) - hence Home Address changes 
and sessions are interrupted.  But that's a separate thread.

Alex

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 25 Apr 2006 13:06:01 +0200

Hi Alex,

thank you very much for your questions and comments about tha draft.
I'll try to reply to all comments below.

> to the HA address.  rfc3775 does specify how to automatically acquire

I disagree. The paragraph simply mentions that the MN needs to know:
- HA address
- HoA
- crypto materials
This is described deeply in the bootstrapping PS draft (currently in
IESG approval). The paragraph does not mention anything about what is
in rfc3775 and what is not.

> MN to derive its Home Address by simple stateless auto-configuration.

Same comment as above, at least for this first paragraph.

However, it seems that your comment on DHAAD and MPD is related to the
whole specification and not only to this paragraph. During the DT
discussion, we have discussed a lot about DHAAD as possible dynamic HA
discovery mechanism. You can find the DT discussion archives at
http://vesuvio.ipv6.cselt.it/pipermail/mip6-boot-sol/

I will try to give more details on this topic below. Note however that
the draft is not deprecating DHAAD nor MPD. The draft is specifying a
bootstrapping procedure that the WG thinks it is needed, even though
someone may keep using DHAAD.

> problem may be this draft which will help to distribute certs.  It doesn't.

certs are one example. The main mechanism described in the documet
relies on IKEv2+EAP. What you mention is that the credentials (e.g.
certs, SIM card) need to be distributed to the MNs; I agree, but I
think this is acceptable.

> still insecure HA Discovery phase (as opposed to the insecure DHAAD).

As mentioned, I would like to rule out from this discussion the
configuration of credentials. There are several ways to provide users
with the right credentials and this is a common problem to all
bootstrapping solutions.

Concerning configuration of FQDN, you are right. The draft is based on
the configuration of a FQDN of the MSP on the MN. The idea is that
this is less cumbersome than configuring IPv6 addresses, in my view
for two reasons: FQDN are more user friendly and do not change,
whereas IPv6 home link prefixes might change.

> Ok, so the objective is to minimize the data pre-configured on the MN.

The objective is to design a bootstrapping solution that is scalable.
The list of detailed goals is provided in the PS draft.

> pre-configured data, not to offer load balancing capability.

This is a second-priority goal. This is something that you may simply
achieve using FQDNs.

> shorter than pre-configuring a domain name.

I think there is a clear difference: home prefixes might change.
Moreover a DNS-based solution gives the flexibility to network
operators to have different home prefixes and not only a fixed one.

> But I do agree the DNS server address could come from the local DHCP server.

Good. So are you suggesting we should rephrase? Can you come up with a
proposed text?

>   How would DNS resolve the right HA for the right MN when the only key

Vijay already replied to this.

So, it seems that your main concern is related to the fact that DHAAD
is not considered in this draft. I think that DHAAD is not deprecated
by this draft, simply there are deployment scenarios where a DNS-based
(or a DHCP-based for integrated scenario) solution is considered more
useful.

Would you suggest any way to improve the draft?

Thanks,
--Gerardo

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 15:18:32 +0200

Hi Gerardo, thanks for the reply.

Gerardo Giaretta wrote:
>> Dear authors of draft-ietf-mip6-bootstrapping-split-02.txt,  I have
>>  read the draft and I have several comments.
>> 
>>> Address, its own Home Address and the cryptographic materials 
>>> (e.g. shared keys or certificates) needed to set up IPsec 
>>> security associations with the Home Agent in order to protect 
>>> Mobile IPv6 signaling. This is generally referred to as the 
>>> Mobile IPv6 bootstrapping problem [4]. [...] Mobile IPv6 base 
>>> protocol does not specify any method to automatically acquire 
>>> this information,
>> That is wrong from many respects. The first and foremost is with 
>> respect to the HA address.  rfc3775 does specify how to 
>> automatically acquire the HA address - DHAAD.
>> 
> 
>  - HA address - HoA - crypto materials This is described deeply in
> the bootstrapping PS draft (currently in IESG approval). The
> paragraph does not mention anything about what is in rfc3775 and what
> is not.

But the text says this:
>>> Mobile IPv6 base protocol does not specify any method to 
>>> automatically acquire this information

That is plain wrong, MIP6 does specify such things.  Please remove this 
phrase.

> I will try to give more details on this topic below. Note however 
> that the draft is not deprecating DHAAD nor MPD. The draft is 
> specifying a bootstrapping procedure that the WG thinks it is needed,
>  even though someone may keep using DHAAD.

Ok.  May I also see it the other way around: someone may use the 
DNS-based bootstrapping method but the WG thought at some point that the 
3775 was to become an RFC.

>> With respect to the crypto material, the certificates more 
>> specifically. Neither Mobile IPv6 nor any other method I'm aware 
>> off will allow MN to "automatically" acquire a cert.  To acquire a 
>> cert one must prove its/his/her identity with an out-of-band 
>> method, non-automatisable.
>> 
>> So stating that the bootstrapping problem lies in the fact that 
>> Mobile IPv6 can't distribute certs makes one think that a solution 
>> to that problem may be this draft which will help to distribute 
>> certs.  It doesn't.
>> 
> 

Yes, but is it scalable?

>>>  manually set configuration data on Mobile Nodes and HAs.
>>> However, in real deployments, manual configuration does not scale
>>> as the Mobile Nodes increase in number.
>> This leaves the reader the impression that while by RFC3775 the 
>> admins will need to manually configure data on MN, this spec would 
>> require no such pre-configuration, thus apparently more scalable. 
>> The first part is plain wrong.  This spec does require the 
>> pre-configuration of something: the HA FQDN.  Should be 
>> acknowledged here, not deep in the document.
>> 
>> The second part (the one that gives the impression that 
>> pre-configuring data on MN is not scaling with the number of MNs) 
>> suddenly becomes a non-supportive argument for this draft.  Because
>>  if pre-configuring data on MN is not scalable then pre-configuring
>>  the FQDN is not scalable either.
>> 
>> Moreover, this spec requires additional data to be pre-configured 
>> on the MN, not just the domain name.  It's the certificates.  They 
>> must be pre-configured on MN in order to somehow avoid the 
>> fallacies of the still insecure HA Discovery phase (as opposed to 
>> the insecure DHAAD).
>> 
> 

Ok, I agree.

> Concerning configuration of FQDN, you are right. The draft is based 
> on the configuration of a FQDN of the MSP on the MN. The idea is that

Please mention in the draft the reasoning that FQDN is more user
friendly than IP addresses and that FQDN would change less frequently
than the prefix.

>  The list of detailed goals is provided in the PS draft.

I've read that.  As with "minimal", "Scalable" is not defined.
"Scalable" doesn't even appear in the PS text.  Scalable of what with
respect to what?

Do you have a rough idea about what "scalable" is?  Other than just
claiming it as an advantage of a proposed method over a vaguely assummed
non-scalable method?

In some contexts, it's like this: the effort to locally maintain
name-address association (/etc/hosts) at each site about each other site
grows exponentially with the number of sites.  It doesn't scale.  The
effort to distributely maintain that database with DNS grows linearly
with the number of sites.  That's more scalable.

So what is "scalable" in the context of DNS-based bootstrapping?  Is it
more scalable to pre-configure fqdn instead of prefixes?  No.  What is
exactly scalable about the DNS-based bootstrapping?

>>> For this reason, the DHAAD defined in [2] may not be applicable 
>>> in real deployments since it is required that the Mobile Node is
>>> and it does not allow an operator to load balance by having 
>>> Mobile Nodes dynamically assigned to Home Agents located in 
>>> different subnets.
> This is a second-priority goal.

Ok.

> This is something that you may simply achieve using FQDNs.

It's not sufficient to just use FQDNs to move some MN from one HA to
another, in a different subnet.  There's need for protocols that haven't
been specified too.

>>>  that is based on Domain Name Service (DNS), introducing a new 
>>> DNS SRV record [5]. The unique information that needs to be 
>>> pre-configured on the Mobile Node is the domain name of the MSP.
>> So there is a need to pre-configure data on the MN, except that 
>> this time we pre-configure the domain name instead of the home 
>> prefix.
>> 
>> Is pre-configuring the domain name more minimal than 
>> pre-configuring the home prefix?  I don't think we can talk in 
>> absolute terms here.  In terms of memory required, a prefix can 
>> take maximum 39 ASCII characters while a domain name may take any 
>> length ("domain" in domain.com can have up to 255 characters).  So 
>> apparently pre-configuring a prefix could be shorter than 
>> pre-configuring a domain name.
>> 
> 

Domain names might change too.  A known peninsular operator research arm
changed just recently, you must be aware of it.

> operators to have different home prefixes and not only a fixed one.

I hope the operators are aware that with that flexibility comes also the
lack of session continuity.  I can explain separately if needed.

>>>  before it can send a DNS request. This can be pre-configured on
>>>  the Mobile Node or obtained through DHCPv6 from the visited link
>>>  [11].
>> Remark this would come in addition to the domain name 
>> pre-configured on the MN.
>> 
> Good. So are you suggesting we should rephrase? Can you come up with 
> a proposed text?

Please remove the entire paragraph stating that MN could be
pre-configured with the DNS Server address (of all visited networks) or
obtained with DHCP.

>  is not considered in this draft. I think that DHAAD is not 
> deprecated by this draft, simply there are deployment scenarios where
>  a DNS-based (or a DHCP-based for integrated scenario) solution is 
> considered more useful.

We seem to be talking past each other.  But I agree with you that there
are deployments that may need this solution.  But just don't say there's
a problem because MIP6 doesn't do this and that.  Some deployments need
something different than what exists not because what exists don't
satisfy them, but because what these deployment prefer is more scalable
and more minimal.

> Would you suggest any way to improve the draft?

As I said above: (1) please define "scalable" and "minimal", (2) please
remove the phrase in the introduction saying MIP6 doesn't deliver the HA
address to the MN (3) please remove the text saying the DNS server
address could be pre-configured on the MN or obtained by DHCP and (4)
please mention in the draft that you've decided to use FQDN instead of
IP addresses as pre-config data because they're more user-friendly and
change less often.

In two separate threads I also suggest: (1) please change the title to
"DNS-based..." and (2) do double-check with straight and reverse DNS
resolution whenever querying the DNS.

Thanks,

Alex

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 25 Apr 2006 16:13:34 +0200

> That is plain wrong, MIP6 does specify such things.  Please remove this

rfc3775 specifies a discovery mechanism based on MN knowing the home
link prefix. This is something is not needed in bootstrapping
solutions and I think the PS document is quite clear. However, if you
think it is needed, we can state that in some scenarios netwrok
operators may still rely on DHAAD, if all MNs are configured with home
link prefixes.

> 3775 was to become an RFC.

And then WG chairs decided to have a DT to solve the bootstrapping problem :)

You may like DHAAD more than DNS-based discovery: that's ok, no
problem to me. This is why I'm not in favor of deprecating DHAAD.

> > think this is acceptable.

Judging from the number of GSM terminals in the world, I think that
having a SIM card with the configured credentials in it, it's quite
scalable.

> friendly than IP addresses and that FQDN would change less frequently

This can be done, if other authors agree to have a comparison between
DNS-based and DHAAD mechanisms. Not sure it is needed, but we can do
that if the WG agrees.

> exactly scalable about the DNS-based bootstrapping?

As mentioned, I think the most important advantage of DNS-based is
that FQDN change rarely. And an operator may change the binding
between names and addresses in the DNS, whereas it cannot change the
home prefixes configured in the terminals.

It seems to me that this is a quite obvious advantage in a real wide
deployment scenario.

> another, in a different subnet.  There's need for protocols that haven't

I'm not saying that you can achieve a fine grained load balancing.
This is clearly stated in the draft. But the operator can change the
addresses that are registered in the DNS. This is not possible if the
addresses are configured in the terminals.

> changed just recently, you must be aware of it.

Good point :)

But the latter happened once in the last 6 years and our mail servers
changed their IP addresses several times during this period. It's a
matter of how much frequent is the event.

> resolution whenever querying the DNS.

I will discuss these proposed changes with other co-authors. I am
against to change the title since the draft specifies several other
procedures and not only HA address discovery.

--Gerardo

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Apr 2006 18:10:21 +0200

Gerardo Giaretta wrote:
> solutions and I think the PS document is quite clear.

We talk past each other.  I'll re-iterate.  The following text in this
draft says:
> signaling.

I agree.

> This is generally referred to as the Mobile IPv6 bootstrapping 
> problem [4].

I don't agree that if MN needs to know its HA/HoA/crypto it means
there's a problem.

> automatically acquire this information [HA/HoA/crypto],

This is wrong - it does.

If you wrote it something like "MIP6 requires MN to pre-configure its
home link prefix, otherwise MIP6 MN can't acquire its HA and HoA" the it
would have expressed what you say in this email.  But it's not written so!

You could write it like this:

A MIP6 MN needs its HA address, its HoA and crypto material for
proper protocol operation.  MIP6 offers MN means to bootstrap
the HA address and HoA with DHAAD and MPD, if the MN is
pre-configured with the home link prefix.  Some operators don't accept
to pre-configure the home link prefix on the MN because it's not
minimal, not scalable, not user-friendly and for various other reasons
(see the PS draft).  Hence a MN bootstrapping issue.  To address
it some operators choose to pre-configure the MN with the fqdn
of its HA (instead of home link prefix) and crypto material.  The
bootstrapping protocol in this document helps MN dynamically acquire its
HA address and HoA, based only on the HA's fqdn (not on home link
prefix) and on crypto material; the initial phase uses stateless address
auto-configuration and DNS querying (to obtain the HA address) while
subsequent phases involve IKE with the HA (obtain HoA and SAs).

> However, if you think it is needed, we can state that in some 
> scenarios netwrok operators may still rely on DHAAD, if all MNs are 
> configured with home link prefixes.

I hope this is captured above, do you think so?  Would you copy paste it
in the draft or modify it?

>>> specifying a bootstrapping procedure that the WG thinks it is 
>>> needed, even though someone may keep using DHAAD.
>> DNS-based bootstrapping method but the WG thought at some point 
>> that the 3775 was to become an RFC.
>> 
> 

Ok.

>>>> specifically. Neither Mobile IPv6 nor any other method I'm 
>>>> aware off will allow MN to "automatically" acquire a cert.  To 
>>>> acquire a cert one must prove its/his/her identity with an 
>>>> out-of-band method, non-automatisable.
>>>> 
>>>>  Mobile IPv6 can't distribute certs makes one think that a 
>>>> solution to that problem may be this draft which will help to 
>>>> distribute certs.  It doesn't.
>>>> 
>>> certs are one example. The main mechanism described in the 
>>> documet relies on IKEv2+EAP. What you mention is that the 
>>> credentials (e.g. certs, SIM card) need to be distributed to the 
>>> MNs; I agree, but I think this is acceptable.
>> Yes, but is it scalable?
>> 
> 

So you just defined what _is_ scalable.  Now what is _not_ scalable?
It's not scalable to pre-configure the home link prefix on each mobile?

>>>> Moreover, this spec requires additional data to be 
>>>> pre-configured on the MN, not just the domain name.  It's the 
>>>> certificates.  They must be pre-configured on MN in order to 
>>>> somehow avoid the fallacies of the still insecure HA Discovery 
>>>> phase (as opposed to the insecure DHAAD).
>>>> 
>>> configuration of credentials. There are several ways to provide 
>>> users with the right credentials and this is a common problem to 
>>> all bootstrapping solutions.
>> Ok, I agree.
>> 
>>> Concerning configuration of FQDN, you are right. The draft is 
>>> based on the configuration of a FQDN of the MSP on the MN. The 
>>> idea is that this is less cumbersome than configuring IPv6 
>>> addresses, in my view for two reasons: FQDN are more user 
>>> friendly and do not change, whereas IPv6 home link prefixes might
>>>  change.
>> friendly than IP addresses and that FQDN would change less 
>> frequently than the prefix.
>> 
> 

I'm not sure we need to compete two different proposals.  I think one is
already RFC for some time and implemented.  I also think that some
operators may prefer the DNS-based bootstrapping.

>> So what is "scalable" in the context of DNS-based bootstrapping? Is
>>  it more scalable to pre-configure fqdn instead of prefixes?  No. 
>> What is exactly scalable about the DNS-based bootstrapping?
>> 
> 
> that FQDN change rarely.

Ok, while I agree that apparently the fqdn and DNS-based method may help
apps hardcode server names - I don't agree MIP6 plays in the apps
league; I don't agree that the DNS-based has any "scalability" advantage
over the DHAAD-based.  If one can't explain what's and what's not
scalable then probably better don't use the word scalable.

> And an operator may change the binding between names and addresses in
> the DNS, whereas it cannot change the home prefixes configured in the
> terminals.

Yes, but an operator can't change the binding between different names 
(an old one and a new one) even with the DNS-based bootstrapping method. 
  When a domain name changes, the way SRV record is spec'ed is such it 
must point to a real record (not a CNAME).  In which case the operator 
will have to change the fqdn's stored in mobiles.

> It seems to me that this is a quite obvious advantage in a real wide

It is, but not perfect.  One can't claim it as _the_ bootstrapping 
method.  One should accept its limitations, in the draft.

>>>>> For this reason, the DHAAD defined in [2] may not be 
>>>>> applicable in real deployments since it is required that the 
>>>>> Mobile Node is pre-configured with the home network prefix
>>>> But was load balancing an objective?  The objective was to 
>>>> minimize pre-configured data, not to offer load balancing 
>>>> capability.
>>>> 
>> It's not sufficient to just use FQDNs to move some MN from one HA 
>> to another, in a different subnet.  There's need for protocols that
>>  haven't been specified too.
>> 
> 
>  addresses that are registered in the DNS. This is not possible if
> the addresses are configured in the terminals.

If the home link prefixes are pre-configured in the terminals, the 
operators can achieve load balancing by re-routing the respective home 
link prefixes in the home network, presumably with netlmm.

MIP6 load balancing can be achieved with DHAAD.  DHAAD was designed for 
load balancing between HAs on the same home link.  Moving the prefix 
from one link to another (within the same home network) is not a MIP6 
problem, but a netlmm problem.

>>>>> This document defines a solution for Home Agent address 
>>>>> discovery that is based on Domain Name Service (DNS), 
>>>>> introducing a new DNS SRV record [5]. The unique information 
>>>>> that needs to be pre-configured on the Mobile Node is the 
>>>>> domain name of the MSP.
>>>>  absolute terms here.  In terms of memory required, a prefix
>>>> can take maximum 39 ASCII characters while a domain name may
>>>> take any length ("domain" in domain.com can have up to 255 
>>>> characters).  So apparently pre-configuring a prefix could be 
>> Domain names might change too.  A known peninsular operator 
>> research arm changed just recently, you must be aware of it.
>> 
> 
> Good point :)
> 

I see it differently.  It is much easier to change a domain name in the 
DNS point it to same previous IP address range than to change the IP 
address block allocated to a certain domain name (witness the reverse 
DNS resolution Vijay expressed previously as being spotty).

Registering a domain name is cheap and getting rid of the old one is 
simply a expiration delay.  Obtaining an IP address range is very 
expensive and one must make sure s/he properly gives back the old 
address range.

Hence, people change much often their domain names than their IP address 
ranges.

> procedures and not only HA address discovery.

Right, I was not proposing to put "HA address discovery" in the title. 
I suggested:
    "DNS-based MIP6 MN bootstrapping in split scenario"

"DNS-based" because it is the first and most fundamental block of all 
the procedure, the most sensitive to security attacks, the strongest 
argument for user-friendliness and scalability.

One co-author seemed to not oppose this title change.  What do you think?

Alex