Subject: IPv6 addresses inside an NSAPA issues

From: "Pandey, Arun" <[email-masked]>
Date: Thu, 29 Jul 2004 03:25:31 -0400

Hi,

RFC 1888 section 'IPv6 addresses inside an NSAPA' does not provide a way to put the tcp port number inside the NSAP. Whereas for IPv4 addresses `RFC 1277 section 4.5  - TCP/IP Network Specific Format` specified a format that allowed the port number to be also specified. For certain applications like the 'OSI Directory services' working in a internet environment it might be required to store and pass the tcp port number along with the IPv6 address. 

Also RFC 1278 that specified a string representation for the presentation address, doesn't seem to have been updated for specifying a string representation for the presentation address to carry IPv6 addresses. The various proposed representations do make space for specifying the port number along with the IPv6 address in the Presentation Address.

This seems to create a situation that if an application is to encode the NSAP, specified in the string representation of the presentation address, as per RFC 1888, it will not be able to encode the port number [if present] along with the IPv6 address, in the NSAPA. This will force the application to store the port number [if present] in an alternate location.

If the application now wants to transfer this encoded Presentation Address to another application:

1) Both the applications would need to agree on an alternate field where to specify the port number, to be able 
    to reconstruct the original presentation address.
or
2) The applications will have to agree on transferring the string encoding of the presentation address to each other. But 
    even for that the string representation of the presentation address for carrying the IPv6 address needs to be agreed 
    upon first.
or
3) A encoding format for IPv6 addresses inside an NSAPA would need to be specified that would allow the carriage of 
   the port number along with the IPv6 address inside an NSAPA.

Each of the above alternatives has its own set of implications. What do others think?  Any opinions or suggestions will be highly appreciated.

Best Regards
Arun Pandey

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jul 2004 10:57:12 +0200

Arun,

1888 is an Experimental RFC that contains health warnings that it
won't work, and as far as I know nobody has ever attempted to
implement it. There also is some interest in the ATM Forum in the
mapping of IP addresses inside NSAP addresses, but that is another
story.

My opinion as the main author of 1888 is that it is well overdue
to be downgraded to Historic, but I was hoping to see a draft from
the ATM people that updates the small part of it that they need, which
is also the part you are interested in.

Without really thinking about it, and with my OSI knowledge having
ten years' rust on it, it seems to me that port numbers belong in
the TSAP address, not the NSAP address. But since I have no idea
why anyone would care, I'd prefer that we simply downgrade the
RFC and forget about. Could I ask whether the WG would support
that? If so the chairs could request the IESG to do it.

Then people interested in the section 'IPv6 addresses inside an NSAPA'
(i.e. you and the ATM Forum) could deal with this as you see fit.

Regards
     Brian

---

From: Brian Haberman <[email-masked]>
Date: Fri, 30 Jul 2004 10:23:42 -0400

Brian,
      As one co-chair, I would support the effort to move RFC 1888
to Historic.  I would also encourage Arun and anyone from the ATM
Forum who is interested in IPv6 addresses in NSAP to submit a draft
on the issue.  If there is interest from the WG, I would support
that work being done here.

Regards,
Brian

Brian E Carpenter wrote:

>> RFC 1888 section 'IPv6 addresses inside an NSAPA' does not provide a 
>> way to put the tcp port number inside the NSAP. Whereas for IPv4 
>> addresses `RFC 1277 section 4.5  - TCP/IP Network Specific Format` 
>> specified a format that allowed the port number to be also specified. 
>> For certain applications like the 'OSI Directory services' working in 
>> a internet environment it might be required to store and pass the tcp 
>> port number along with the IPv6 address.
>> Also RFC 1278 that specified a string representation for the 
>> presentation address, doesn't seem to have been updated for specifying 
>> a string representation for the presentation address to carry IPv6 
>> addresses. The various proposed representations do make space for 
>> specifying the port number along with the IPv6 address in the 
>> Presentation Address.
>>
>> This seems to create a situation that if an application is to encode 
>> the NSAP, specified in the string representation of the presentation 
>> address, as per RFC 1888, it will not be able to encode the port 
>> number [if present] along with the IPv6 address, in the NSAPA. This 
>> will force the application to store the port number [if present] in an 
>> alternate location.
>>
>> 1) Both the applications would need to agree on an alternate field 
>> where to specify the port number, to be able     to reconstruct the 
>> original presentation address.
>> or
>> 2) The applications will have to agree on transferring the string 
>> encoding of the presentation address to each other. But     even for 
>> that the string representation of the presentation address for 
>> carrying the IPv6 address needs to be agreed     upon first.
>> or
>> 3) A encoding format for IPv6 addresses inside an NSAPA would need to 
>> be specified that would allow the carriage of    the port number along 
>> with the IPv6 address inside an NSAPA.
>>
>> Each of the above alternatives has its own set of implications. What 
>> do others think?  Any opinions or suggestions will be highly appreciated.
>>
>> Best Regards
>> Arun Pandey
>>
>>

---

From: "EricLKlein" <[email-masked]>
Date: Fri, 30 Jul 2004 19:52:22 +0300

Although I agree that this should be downgraded to historical status, I
would not count on the ATM Forum doing anything with it any time soon as
last week there was an announcement of the planned merger of the ATM Forum
with the MPLS and Frame Relay Alliance.

It seems to me that the new combined organization will have it's hands full
for the transition period.
Eric

---

From: Bob Hinden <[email-masked]>
Date: Fri, 30 Jul 2004 12:01:35 -0700

Brian,

>that? If so the chairs could request the IESG to do it.

I would also support doing this.  I think a good next step would be for you 
to write a short ID (e.g., Reclassification of IPV6 NSAP Addresses to 
Historic) with a little background and IANA instructions.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Jul 2004 14:52:22 +0200

OK. But no promise about when.

I think we will have to leave existing IANA assignments in place,
but I will think a bit more about that.

   Brian

Bob Hinden wrote:
> I would also support doing this.  I think a good next step would be for 
> you to write a short ID (e.g., Reclassification of IPV6 NSAP Addresses 
> to Historic) with a little background and IANA instructions.
> 
> Thanks,
> Bob
> 
> 
> 
>