Skip to main content

Dynamic Hostname Exchange Mechanism for OSPF
RFC 5642

Revision differences

Document history

Date Rev. By Action
2015-10-14
05 (System) Notify list changed from ospf-chairs@ietf.org, draft-ietf-ospf-dynamic-hostname@ietf.org to (None)
2012-08-22
05 (System) post-migration administrative database adjustment to the Yes position for Adrian Farrel
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Lars Eggert
2009-08-21
05 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2009-08-21
05 Amy Vezza [Note]: 'RFC 5642' added by Amy Vezza
2009-08-20
05 (System) RFC published
2009-07-21
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2009-07-21
05 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2009-07-21
05 (System) IANA Action state changed to In Progress from Waiting on Authors
2009-07-20
05 Cindy Morgan State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan
2009-07-20
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2009-07-20
05 (System) IANA Action state changed to In Progress
2009-07-20
05 Cindy Morgan IESG state changed to Approved-announcement sent
2009-07-20
05 Cindy Morgan IESG has approved the document
2009-07-20
05 Cindy Morgan Closed "Approve" ballot
2009-07-20
05 Ross Callon State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon
2009-07-17
05 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to Yes from Discuss by Adrian Farrel
2009-07-17
05 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert
2009-07-12
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2009-07-12
05 (System) New version available: draft-ietf-ospf-dynamic-hostname-05.txt
2009-07-03
05 (System) Removed from agenda for telechat - 2009-07-02
2009-07-02
05 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Sam Weiler.
2009-07-02
05 Cindy Morgan State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan
2009-07-02
05 Robert Sparks
[Ballot comment]
(moved to a comment after having it pointed out that the text limits the field to 255 octets - potential exhaustion still exists, …
[Ballot comment]
(moved to a comment after having it pointed out that the text limits the field to 255 octets - potential exhaustion still exists, but is harder. Missing that limit in the implementation of a sender could still lead to problems).

I think a little more advice in the Security Considerations section on protection from accidental misconfiguration causing problems might be in order.

This mechanism causes routers to keep new state (adding domain names to a table). The mechanism can provide names that are large (effectively bounded by the size of an OSPF message). It's not hard to imagine someone fat-fingering a configuration file (missing a quote or the equivalent) and ending up with a very large "domain name".
2009-07-02
05 Robert Sparks [Ballot discuss]
2009-07-02
05 Robert Sparks [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks
2009-07-02
05 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2009-07-02
05 Dan Romascanu
[Ballot comment]
The OPS-DIR review by David Kessens raised a number of issues that make this document problematic although not enough to block it at …
[Ballot comment]
The OPS-DIR review by David Kessens raised a number of issues that make this document problematic although not enough to block it at this phase:

1. The authors chose to overload the protocol with an option for a problem that looks more like a management problem and is solved in real life by good network management techniques. The arguments about scaling issues for a stored mapping table do not seem credible. One can expect that routers in a reasonable sized network are already configured by use of a central database and configuring an extra table should not be a problem at all. Furthermore, there are security issues with the choosen approach that a configured table doesn't have and it seems that it might be easier to avoid name conflicts with a centrally configured table. The security concerns are apprpiately identified in the document, ans it seems safer to use a configured table which does not have such problems.

2. There are issues with the interpretation of what an ID to hostname mapping actually means, and what it should and should not be used for. The term hostname is used but there are only hints that an OSPF hostname might be the same as what one stores in the DNS as a hostname for a particular router. Eg. is the hostname just an easy human readible name or is it supposed to be the same as a real hostname that also maps to an IP address used by the router.
2009-07-02
05 Dan Romascanu
[Ballot comment]
The OPS-DIR review by David Kessens raised a number of issues that make this document problematic although not enough to block it at …
[Ballot comment]
The OPS-DIR review by David Kessens raised a number of issues that make this document problematic although not enough to block it at this phase:

1. The authors chose to overload the protocol with an option for a problem that looks more like a management problem and is solved in real life by good network management techniques. The arguments about scaling issues for a stored mapping table do not seem credible. One can expect that routers in a reasonable sized network are already configured by use of a central database and configuring an extra table should not be a problem at all. Furthermore, there are security issues with the choosen approach that a configured table doesn't have and it seems that it might be easier to avoid name conflicts with a centrally configured table. The security concerns are apprpiately identified in the document, ans it seems safer to use a configured table which does not have such problems.

2. There are issues with the interpretation of what an ID to hostname mapping actually means, and what it should and should not be used for. The term hostname is used but there are only hints that an OSPF hostname might be the same as what one stores in the DNS as a hostname for a particular router. Eg. is the hostname just an easy human readible name or is it supposed to be the same as a real hostname that also maps to an IP address used by the router.



2.
2009-07-02
05 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2009-07-01
05 Lisa Dusseault
[Ballot comment]
I agree with the comment that this draft should be more clear in the difference between a hostname and a display name for …
[Ballot comment]
I agree with the comment that this draft should be more clear in the difference between a hostname and a display name for a router.  Using the terms 'host' and "host name" imply that the node is reachable at that host name.  OTOH if this was just a display name, then presumably RFC3490 wouldn't apply.
2009-07-01
05 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2009-07-01
05 Robert Sparks
[Ballot discuss]
I think a little more advice in the Security Considerations section on protection from accidental misconfiguration causing problems might be in order.

This …
[Ballot discuss]
I think a little more advice in the Security Considerations section on protection from accidental misconfiguration causing problems might be in order.

This mechanism causes routers to keep new state (adding domain names to a table). The mechanism can provide names that are large (effectively bounded by the size of an OSPF message). It's not hard to imagine someone fat-fingering a configuration file (missing a quote or the equivalent) and ending up with a very large "domain name".
2009-07-01
05 Robert Sparks [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks
2009-07-01
05 Lars Eggert
[Ballot comment]
INTRODUCTION, paragraph 2:
> Dynamic Hostname Exchange Mechanism for OSPF

  The names exchanged in this option name *routers*, not hosts. The
  …
[Ballot comment]
INTRODUCTION, paragraph 2:
> Dynamic Hostname Exchange Mechanism for OSPF

  The names exchanged in this option name *routers*, not hosts. The
  terminology is hence pretty confusing.

Section 2., paragraph 5:
>    This specification provides these semantics
>    and mapping mechanisms for OSPFv2 and OSPFv3, leveraging the OSPF
>    Router Information (RI) LSA ([RFC4970]).

  Please expand acronyms on first use (LSA, etc.)


Section 3.1., paragraph 6:
>    The use of FQDN or a subset of
>    it is strongly recommended.

  s/recommended/RECOMMENDED/


Section 8.2., paragraph 4:
>    [RFC2763]  Shen, N. and H. Smit, "Dynamic Hostname Exchange Mechanism
>              for IS-IS", RFC 2763, February 2000.

  Obsolete informational reference (is this intentional?): RFC 2763
  (Obsoleted by RFC 5301)
2009-07-01
05 Lars Eggert
[Ballot discuss]
Section 5., paragraph 1:
>    Since the hostname-to-Router ID mapping relies on information
>    provided by the routers themselves, a misconfigured …
[Ballot discuss]
Section 5., paragraph 1:
>    Since the hostname-to-Router ID mapping relies on information
>    provided by the routers themselves, a misconfigured or compromised
>    router can inject false mapping information, including a duplicate
>    hostname for different Router IDs.  Thus, this information needs to
>    be treated with suspicion when, for example, doing diagnostics about
>    a suspected security incident.

  DISCUSS: That's certainly true, but I'd like the document to specify
  some mechanisms to prevent foot-shooting. For example, when two or
  more routers are (mis)configured with the same name, should a router
  that detects this still blindly flood this information without even a
  management alert? Even when someone else is using "my" name? Even ARP
  stacks these days raise a "MAC address foo is using my IP adress bar"
  alerts.
2009-07-01
05 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert
2009-07-01
05 Adrian Farrel
[Ballot comment]
Section 1
  It is obvious that...
I *hate* being told that something is obvious. This text does not add anything to the …
[Ballot comment]
Section 1
  It is obvious that...
I *hate* being told that something is obvious. This text does not add anything to the I-D.

Section 2
s/DNS can be used for the same./DNS could be used for this./
s/Routers who don't understand/Routers that don't understand/

Section 3
  The Dynamic Hostname TLV (see Section 3.1) is OPTIONAL.  Upon receipt
  of the TLV a router may decide to ignore this TLV, or to install the
  symbolic name and Router ID in its hostname mapping table.
Is it worth highlighting that "ignore" means "not act on, but continue to flood as part of the LSA." ?

Section 3.1
  Value    Hostname, a string of 1 to 255 octets, padded to 4-octet
            alignment, encoded in the US-ASCII charset.
Do you care whether this is padded with any character?

FQDN should be expanded on first use.
2009-07-01
05 Adrian Farrel
[Ballot discuss]
I really wanted to vote "yes" notwithstanding a number of Comments, but I think the security section warrants some discussion...

It seems to …
[Ballot discuss]
I really wanted to vote "yes" notwithstanding a number of Comments, but I think the security section warrants some discussion...

It seems to me that the FQDN potentially exposes geographic or other commercial information that may be embedded in or deduced from the hostname. Sending this information in the clear is therefore a security risk that should at least be indicated in the security section (even if you are not proposing any solution).
2009-07-01
05 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded by Adrian Farrel
2009-06-30
05 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2009-06-30
05 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica
2009-06-30
05 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms
2009-06-30
05 Ralph Droms
[Ballot comment]
Is there any impact from name collisions if two routers use the same Dynamic Hostname.  I don't think there is other than potential …
[Ballot comment]
Is there any impact from name collisions if two routers use the same Dynamic Hostname.  I don't think there is other than potential confusion in reading and using the mapping information.  For completeness, it might be useful to add a couple of sentences explaining that name conflicts aren't crucial and, therefore, there is no conflict detection or resolution in the protocol.

Editorial suggestion: expand "FQDN" on first use in section 3.1?  I don't understand this sentence in section 3.1:

  The content of this value is a domain
  name, see [RFC2181].

"this value" == value field in the Dynamic Hostname TLV?  What does it mean for the dynamic hostname to be a "domain name"?  Can't it also be an arbitrary identifier chosen by the OSPF admin or does it somehow have to relate to a name from the DNS?
2009-06-29
05 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2009-06-25
05 Alexey Melnikov
[Ballot comment]
draft-ietf-ospf-dynamic-hostname-04.txt

  The value field identifies the symbolic hostname of the router
  originating the LSA.  This symbolic name can be the FQDN …
[Ballot comment]
draft-ietf-ospf-dynamic-hostname-04.txt

  The value field identifies the symbolic hostname of the router
  originating the LSA.  This symbolic name can be the FQDN for the
  router, it can be a subset of the FQDN,

What exactly is "subset of the FQDN"?

  or it can be any string
  operators want to use for the router.

Is it actually a good idea to allow anything other than domain names in this field?

  The use of FQDN or a subset of
  it is strongly recommended.  The content of this value is a domain
  name, see [RFC2181].  The string is not null-terminated.  The Router
  ID of this router is derived from the LSA header, in the Advertising
  Router field of the Router Information (RI) Opaque LSA.
2009-06-24
05 Ross Callon Placed on agenda for telechat - 2009-07-02 by Ross Callon
2009-06-24
05 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2009-06-24
05 Ross Callon Ballot has been issued by Ross Callon
2009-06-24
05 Ross Callon Created "Approve" ballot
2009-06-24
05 Ross Callon State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon
2009-06-17
04 (System) New version available: draft-ietf-ospf-dynamic-hostname-04.txt
2009-06-16
05 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2009-06-10
05 Amanda Baber
IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "OSPF Router Information (RI) TLVs" registry at
http://www.iana.org/assignments/ospfv2-parameters/

Value Description …
IANA comments:

Upon approval of this document, IANA will make the following
assignment in the "OSPF Router Information (RI) TLVs" registry at
http://www.iana.org/assignments/ospfv2-parameters/

Value Description Reference
------- --------------------------------------------- ---------
TBD OSPF Dynamic Hostname [RFC-ospf-dynamic-hostname-03]

We understand the above to be the only IANA Action for this document.
2009-06-05
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Weiler
2009-06-05
05 Samuel Weiler Request for Last Call review by SECDIR is assigned to Sam Weiler
2009-06-02
05 Cindy Morgan Last call sent
2009-06-02
05 Cindy Morgan State Changes to In Last Call from Last Call Requested by Cindy Morgan
2009-06-02
05 Ross Callon Last Call was requested by Ross Callon
2009-06-02
05 Ross Callon State Changes to Last Call Requested from AD Evaluation by Ross Callon
2009-06-02
05 (System) Ballot writeup text was added
2009-06-02
05 (System) Last call text was added
2009-06-02
05 (System) Ballot approval text was added
2009-04-13
05 Ross Callon State Changes to AD Evaluation from Publication Requested by Ross Callon
2009-04-05
05 Ross Callon
PROTO writeup by Acee Lindem:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do …
PROTO writeup by Acee Lindem:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes - I've reviewed it myself several times.

    Do you have any concerns about the depth or
    breadth of the reviews that have been performed?
   
    No

  3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any event,
    if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No

  5. How solid is the WG consensus behind this document? Does it represent
    the strong concurrence of a few individuals, with others being silent,
    or does the WG as a whole understand and agree with it?

    The draft is already implemented and deployed in the ISIS protocol.
    Given this experience, I see no problems with standardization.

  6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items?

idnits 2.11.08

tmp/draft-ietf-ospf-dynamic-hostname-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Obsolete informational reference (is this intentional?): RFC 2763
    (Obsoleted by RFC 5301)


    Summary: 0 errors (**), 0 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

  8. Is the document split into normative and informative references?

    Yes

    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state? (note
    here that the RFC editor will not publish an RFC with normative
    references to IDs, it will delay publication until all such IDs
    are also ready for publication as RFCs.)

    No

  9. What is the intended status of the document? (e.g., Proposed Standard,
    Informational?)

    Proposed Standard

10. For Standards Track and BCP documents, the IESG approval announcement
    includes a write-up section with the following sections:

    * Technical Summary

      This draft extends OSPF to enable advertisement of a hostname for
      human readable identification of OSPF routrs.

    * Working Group Summary

      There is no opposition to the draft and the consensus on adding the
      equivalent to the ISIS feature.

    * Protocol Quality

      This is a very straight forward draft and has already been implemented
      in ISIS. The draft has been reviewed several times and we see no issues.
2009-04-05
05 Ross Callon
PROTO writeup by Acee Lindem:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do …
PROTO writeup by Acee Lindem:

  1. Have the chairs personally reviewed this version of the Internet
    Draft (ID), and in particular, do they believe this ID is ready
    to forward to the IESG for publication?

    Yes

  2. Has the document had adequate review from both key WG members and
    key non-WG members?

    Yes - I've reviewed it myself several times.

    Do you have any concerns about the depth or
    breadth of the reviews that have been performed?
   
    No

  3. Do you have concerns that the document needs more review from a
    particular (broader) perspective (e.g., security, operational
    complexity, someone familiar with AAA, etc.)?

    No

  4. Do you have any specific concerns/issues with this document that
    you believe the ADs and/or IESG should be aware of? For example,
    perhaps you are uncomfortable with certain parts of the document,
    or have concerns whether there really is a need for it. In any event,
    if your issues have been discussed in the WG and the WG has
    indicated it that it still wishes to advance the document, detail
    those concerns in the write-up.

    No

  5. How solid is the WG consensus behind this document? Does it represent
    the strong concurrence of a few individuals, with others being silent,
    or does the WG as a whole understand and agree with it?

    The draft is already implemented and deployed in the ISIS protocol.
    Given this experience, I see no problems with standardization.

  6. Has anyone threatened an appeal or otherwise indicated extreme
    discontent? If so, please summarise the areas of conflict
    in separate email to the Responsible Area Director.

    No

  7. Have the chairs verified that the document adheres to all
    of the ID Checklist items?

idnits 2.11.08

tmp/draft-ietf-ospf-dynamic-hostname-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Obsolete informational reference (is this intentional?): RFC 2763
    (Obsoleted by RFC 5301)


    Summary: 0 errors (**), 0 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.
--------------------------------------------------------------------------------

  8. Is the document split into normative and informative references?

    Yes

    Are there normative references to IDs, where the IDs are not
    also ready for advancement or are otherwise in an unclear state? (note
    here that the RFC editor will not publish an RFC with normative
    references to IDs, it will delay publication until all such IDs
    are also ready for publication as RFCs.)

    No

  9. What is the intended status of the document? (e.g., Proposed Standard,
    Informational?)

    Proposed Standard

10. For Standards Track and BCP documents, the IESG approval announcement
    includes a write-up section with the following sections:

    * Technical Summary

      This draft extends OSPF to enable advertisement of a hostname for
      human readable identification of OSPF routrs.

    * Working Group Summary

      There is no opposition to the draft and the consensus on adding the
      equivalent to the ISIS feature.

    * Protocol Quality

      This is a very straight forward draft and has already been implemented
      in ISIS. The draft has been reviewed several times and we see no issues.
2009-04-03
05 Ross Callon Draft Added by Ross Callon in state Publication Requested
2009-04-03
03 (System) New version available: draft-ietf-ospf-dynamic-hostname-03.txt
2009-02-26
02 (System) New version available: draft-ietf-ospf-dynamic-hostname-02.txt
2008-10-14
01 (System) New version available: draft-ietf-ospf-dynamic-hostname-01.txt
2008-04-15
00 (System) New version available: draft-ietf-ospf-dynamic-hostname-00.txt